Synchronization issue

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
Post Reply
vper
Junior Member
Posts: 4
Joined: Thu Feb 28, 2013 9:21 am

Synchronization issue

Post by vper »

Hi,

I am now using the last Reference Design version (5.2.0beta4), which allows the TALKER or LISTENER Entities to be deactivated.

I am testing the design with 2 LC Boards, either connecting them through a LabX Switch or directly.

I have found out that if I deactivate the TALKER on one of the LC Boards, the LRCLKs are not synchronized anymore (even if there is audio coming out, the LRCLKs are continuously drifting, therefore losing audio samples every now and then).

Nevertheless, if I deactivate the TALKER on the other board (and activating TALKER and LISTENER on the other), the LRCLKs are always phase locked.

That means, the problem is only appearing on one of the boards (always the same).

Finally, I have found out that if I comment the following lines in simple_demo_controller.c, the issue dissappears:

Code: Select all

    // If we were previously master clock, restore this on connection to an XMOS talker
    if (talker_guid->l < my_guid->l)
    {
      set_device_media_clock_type(0, DEVICE_MEDIA_CLOCK_LOCAL_CLOCK);
      printstrln("Entity elected Master audio clock");
    }
Incidentally, the board experiencing the issue is the one which is always a PTP Slave (PTP Master is either the Switch or the other board).

Could anyone please explain me why is this happening?

Thanks!


User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Post by Andy »

Hi vper,

Normally it should be the role of a external 1722.1 Controller to setup the clocking of devices on the network. The demo app provides a simple controller for setting up connections when 2 XMOS endpoints are connected on the network. It doesn't currently handle clocking for setups other than the default Talker+Listener setup.

The problem is that the Listener is accidentally setting itself to not recover a clock from the incoming stream. It doesn't check if it can source a stream and the remote endpoint can sink a stream.

I'll send some improved code on your xmos.com ticket.
vper
Junior Member
Posts: 4
Joined: Thu Feb 28, 2013 9:21 am

Post by vper »

Great! Thanks!
Post Reply