Partilhar via


Relógios Mestres

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

A interface para um relógio mestre é um objeto de arquivo que suporta métodos, propriedades e eventos.

Todas as consultas em relação ao objeto de arquivo estão disponíveis somente em PASSIVE_LEVEL. No entanto, a consulta da posição do relógio também é suportada por meio de um ponteiro para chamada de função direta disponível no DISPATCH_LEVEL, que permanece válido enquanto o objeto de arquivo for 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, da mesma forma que a criação de pinos é 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 pino é 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 mestre para filtros de modo kernel. No momento em que o filtro está sendo atribuído ao relógio mestre do gráfico, uma instância de pino pode consultar o objeto de arquivo pai para determinar se ele possui o relógio mestre.

Quando um filtro recebe o identificador de arquivo para esse relógio mestre, o filtro pode então ser usado para consultar propriedades. Se um relógio mestre estiver baseado num filtro de modo kernel, deverá suportar uma interface para consultar o identificador de arquivo para a parte de modo kernel do relógio mestre. Se a interface não for suportada, então presume-se que o relógio é baseado no modo de usuário, e os filtros de modo kernel não podem sincronizar com ele.

O filtro proxy DirectShow que solicita a alça de relógio mestre passa-a para a alça de filtro de modo kernel subjacente. O filtro kernel-mode faz referência ao objeto de arquivo subjacente. Se o filtro já tinha um relógio mestre, ele desreferencia o objeto de arquivo e usa o novo identificador. Para fazer isso, o filtro deve estar no estado Parar.

O tempo físico no objeto de relógio mestre é freqüentemente baseado em hardware. Se um filtro que apresenta o relógio mestre não tiver relógio físico, então o tempo do fluxo progride de acordo com os carimbos de data/hora dos dados apresentados. Em tal situação, os timestamps podem parar devido à falta de dados.

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