mic_array_get_next_time_domain_frame in a select? Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 487
Joined: Wed Apr 25, 2012 8:52 pm

mic_array_get_next_time_domain_frame in a select?

Post by aclassifier »

I am wondering whether it's possible to put mic_array_get_next_time_domain_frame of lib_mic_array file decimator_interface.xc into a select.

What first sprung to my mind was whether I could use the first thing that mic_array_get_next_time_domain_frame does in a select:

Code: Select all

for(unsigned i=0;i<decimator_count;i++)
      schkct(c_from_decimator[i], 8);
Like select case c_from_decimator[0] and then modify the library code to

Code: Select all

for(unsigned i=1;i<decimator_count;i++)
      schkct(c_from_decimator[i], 8);
schkct(c_from_decimator[ i ], 8); "Checks for a control token of a given value on a streaming channel end. If the next byte in the channel is a control token which matches the expected value then it is input and discarded, otherwise an exception is raised."

I don't know if this is a channel input as such (looking into the .build files leaves me with my eyes wide open, but nothing goes from there). And it it were, if I am allowed to input on it. (Update: I know that this channel contains pointers to data from the application to the decimators, used by the decimators to point to frames valid for the application to read from, but still I am in the unclear about this schkct).

The alternative way is to wrap it into an always ready timerafter, which seems to work. From

Code: Select all

while(1) {
    mic_array_get_next_time_domain_frame...
    ...
}
to

Code: Select all

while(1) {
    select {
        case tmr when timerafter (timeout_tics) :> void: {
            mic_array_get_next_time_domain_frame...
            ...
            tmr :> timeout_tics;
        } break;
    select some other channel..
    }
}
but I am not certain about the timing requirements of mic_array_get_next_time_domain_frame, even if xta seems satisfied when building with lib_mic_array.
Off Topic


--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
View Solution
User avatar
aclassifier
Respected Member
Posts: 487
Joined: Wed Apr 25, 2012 8:52 pm

Post by aclassifier »

Closing this, the suggested way to do it works very well. Here is some pesudo code that works. This shows how the asynch deadlock free pattern "knock-come!" is also "using" one select case. Observe [[ordered]], which must be there:

tmr :> time_when_samples_ready_ticks;
while (1) {
    [[ordered]]
    select {

        case ch_ab_bidir :> data_ch_ab_bidir : {
            // Handle come-data:
            ch_ab_bidir <: data_ch_ab_bidir;
        } break;

        case tmr when timerafter (timeout_ticks) :> void: {
            mic_array_get_next_time_domain_frame(..);
            // handle
            // Knock (if state allows):
            ch_ba_knock <: data_ch_ba_knock; 
            if (headset_gain_off) {
                // Do nothing here
            } else {
                // handle
                ch_headset_out <: output_to_dac; 
                ch_headset_out <: output_to_dac;
            }
            // handle timeout_ticks
        } break;
    }
}
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/