Repeated clock switching between ADAT and Internal causes MacOS to hang

[shuchitak]

When running the ADAT input test, the clock source is switched from Internal -> ADAT at the beginning of the test and ADAT -> Internal at the end of the test.

When running this test with a higher channel count configuration (noticed in the 2AMi30o30xxxaax config), the MIDI interface seems to go unresponsive on the 4th iteration.
For example, when running the test for samp freqs [44100, 48000, 88200, 96000], after running for 96000, the dut.set_clock_src("Internal") command times out reporting that the DUT is inaccessible.

Few things I've noticed:

• The failure is not dependant on sampling rate. Even running something like [48000, 48000, 48000, 48000], so the same sampling rate 4 times, it goes unresponsive on the 4th iteration
• The failure is not dependant on streaming audio over USB. Even without any USB streaming, the error happens on the 4th iteration.
• The failure is not dependant on HiBW implemenation. When compiling 2AMi30o30xxxaax without HiBW enabled, and testing at 48KHz, the same error happens. It seems to happen for a higher channel count configuration.
• The error can be recreated outside the test.
  • xrun the DUT. In separate terminals run the audio analyzer and the xscope controller.
    xrun --id 0 --xscope bin/2AMi30o30xxxxxx_hibw/app_usb_aud_xk_316_mc_2AMi30o30xxxxxx_hibw.xe
    xrun --id 1 --xscope-port localhost:12345 app_audio_analyzer_xcore200_mc_adat_test.xe
    ./xscope_controller localhost 12345 30 "f 48000"
  • The audio analyzer should be producing ADAT ouput data that is input to the DUT. The clocks can be switched now.
  • From the MacOS MIDI interface, switch the clocks between Internal and ADAT. After a few tries, the MIDI interface becomes unresponsive.
  • Instead of MIDI interface, you could use the volcontrol executable to change the clks.
    ./volcontrol --clock Internal
    ./volcontrol --clock ADAT
    • After a few times switching, volcontrol also hangs.

I couldn't recreate this issue on Windows.

To work around this, in the adat input test, I've swapped the order of the with and the for to start and kill a DUT instance for every sampling rate, and this seems to fix the problem.

for fs in features["samp_freqs"]:
with AppUsbAudDut(adapter_dut, board, config) as dut: dut.run_test(fs)