Relógios Mestres

Os minidrivers podem sincronizar fluxos com relógios criados por outros minidrivers; vários fluxos podem ser sincronizados com um relógio. Se o pino usar ou produzir um relógio master, o minidriver deverá dar suporte a KSPROPERTY_STREAM_MASTERCLOCK. Os clientes também podem usar essa propriedade para definir o relógio master para o pino. Os pinos que executam operações de renderização e captura frequentemente usam um relógio master. O minidriver é responsável por liberar referências de relógio após a terminação.

A interface para um relógio master é um objeto de arquivo que dá suporte a métodos, propriedades e eventos.

Todas as consultas no objeto de arquivo estão disponíveis apenas em PASSIVE_LEVEL. No entanto, a consulta de posição do relógio também tem suporte por meio de um ponteiro de chamada de função direta disponível em DISPATCH_LEVEL, que é válido desde que o objeto de arquivo seja válido. Essa chamada direta deve ser passada para o objeto de arquivo do relógio como um parâmetro de contexto.

O identificador de arquivo é adquirido por meio de uma solicitação de criação em uma instância de pino de filtro, assim como a criação do pino é feita por IRP_MJ_CREATE. A solicitação faz com que um identificador de arquivo seja criado, assim como um identificador de arquivo para um pin é criado, com suas próprias informações de contexto. Esse identificador de arquivo é então passado de volta para o chamador e pode ser usado para definir o relógio master para filtros do modo kernel. No momento em que o filtro está sendo atribuído ao relógio master do grafo, uma instância de pino pode consultar o objeto de arquivo pai para determinar se ele possui o relógio master.

Quando um filtro recebe o identificador de arquivo para esse relógio master, ele pode ser usado para consultar propriedades. Se um relógio master for baseado em um filtro de modo kernel, ele deverá dar suporte a uma interface para consultar o identificador de arquivo para a parte do modo kernel do relógio master. Se não houver suporte para a interface, supõe-se que o relógio é baseado no modo de usuário e os filtros do modo kernel não podem ser sincronizados com ela.

O filtro de proxy do DirectShow solicitando o identificador do relógio master e, em seguida, passa-o para o identificador de arquivo de filtro do modo kernel subjacente. O filtro de modo kernel faz referência ao objeto de arquivo subjacente. Se o filtro já tiver um relógio master, ele desreferenciará o objeto de arquivo e usará o novo identificador. Para fazer isso, o filtro deve estar no estado Parar.

O tempo físico no objeto de relógio master é frequentemente baseado em hardware. Se um filtro que apresenta o relógio master não tiver relógio físico, o tempo de fluxo progride de acordo com os carimbos de data/hora dos dados apresentados. Nessa situação, os carimbos de data/hora podem parar devido à falta de dados.

O tempo físico por trás do relógio master pode ser remoto, nesse caso, é responsabilidade do proxy local fornecer leituras precisas. Por exemplo, o proxy tem a responsabilidade de compensar o atraso em uma conexão 1394 ou média do atraso em uma rede. Além disso, se algum outro filtro de kernel for um proxy para um segundo dispositivo no mesmo barramento 1394, os dois dispositivos poderão negociar um método privado de interfiguração com o relógio master. Nesse caso, os dispositivos devem usar interfaces privadas para determinar o tipo de relógio para verificar a compatibilidade.