Ссылка класса IOUSBInterfaceInterface192


    
    LowLatencyCreateBuffer
    - LowLatencyCreateBuffer

Выделяет буфер типа bufferType.

Объявление

C++

IOReturn ( *LowLatencyCreateBuffer)( void *self, void **buffer, IOByteCount size, UInt32 bufferType);

Параметры

`self`	Указатель на IOUSBInterfaceInterface.
`buffer`	Указатель на указатель, который получит указатель на буфер, создаваемый этим вызовом.
`size`	Размер буфера, который будет создаваться в байтах.
`bufferType`	Тип буфера: один из kUSBLowLatencyWriteBuffer, kUSBLowLatencyReadBuffer, или kUSBLowLatencyFrameListBuffer. См. документацию для USB.h.

Возвращаемое значение

Возвраты kIOReturnSuccess в случае успеха, kIOReturnNoDevice, если нет никакого соединения с IOService или kIOReturnNotOpen, если интерфейс не открыт для эксклюзивного доступа. Если буфер не может быть выделен, он возвратит kIOReturnNoMemory.

Обсуждение

Эта функция выделяет буфер типа bufferType. Буфер может тогда использоваться с LowLatencyIsochReadPipeAsync () или LowLatencyIsochWritePipeAsync () вызовы.

LowLatencyIsochReadPipeAsync () или LowLatencyIsochWritePipeAsync () вызовы требуют, чтобы клиенты предварительно выделили буфер данных и буферные параметры списка кадра. Этот вызов используется для выделения тех буферов. После того, как клиент сделан с помощью буферов, они должны быть выпущены через LowLatencyDestroyBuffer () вызов.

Если буфер должен использоваться для чтения данных, тип передал в, должен быть kUSBLowLatencyReadBuffer. Если буфер должен использоваться для записи данных, тип должен быть kUSBLowLatencyWriteBuffer. Для данных списка кадра тип должен быть kUSBLowLatencyFrameListBuffer.

Клиент может создать многократные данные и структурировать буферы списка, или они могут выделить большой буфер и затем использовать только часть буфера в вызовах к LowLatencyReadIsochPipeAsync () или LowLatencyWriteIsochPipeAsync ().

Интерфейс должен быть открыт для канала для существования.


    
    LowLatencyDestroyBuffer
    - LowLatencyDestroyBuffer

Выпускает буфер, ранее выделенный с помощью LowLatencyCreateBuffer ().

Объявление

C++

IOReturn ( *LowLatencyDestroyBuffer) ( void *self, void *buffer );

Параметры

`self`	Указатель на IOUSBInterfaceInterface.
`buffer`	Указатель на буфер ранее выделил использование LowLatencyCreateBuffer ().

Возвращаемое значение

Возвраты kIOReturnSuccess в случае успеха, kIOReturnNoDevice, если нет никакого соединения с IOService или kIOReturnNotOpen, если интерфейс не открыт для эксклюзивного доступа. Если буфер не был ранее выделен с помощью LowLatencyCreateBuffer (), это возвратит kIOReturnBadArgument.

Обсуждение

Интерфейс должен быть открыт для канала для существования.


    
    LowLatencyReadIsochPipeAsync
    - LowLatencyReadIsochPipeAsync

Выполняет асинхронное чтение на изохронном канале и обновляет список кадра в основное время прерывания.

Объявление

C++

IOReturn ( *LowLatencyReadIsochPipeAsync)( void *self, UInt8 pipeRef, void *buf, UInt64 frameStart, UInt32 numFrames, UInt32 updateFrequency, IOUSBLowLatencyIsocFrame *frameList, IOAsyncCallback1 callback, void *refcon);

Параметры

`self`	Указатель на IOUSBInterfaceInterface.
`pipeRef`	Индекс для желаемого канала (1 - GetNumEndpoints).
`buf`	Буфер для содержания данных, ранее выделенных с LowLatencyCreateBuffer () использование типа kUSBLowLatencyReadBuffer.
`frameStart`	Число кадра шины, на котором можно запустить чтение (полученный из GetBusFrameNumber).
`numFrames`	Число кадров, для которых можно передать данные.
`updateFrequency`	Указывает, как часто в миллисекундах должны быть обновлены данные списка кадра. Допустимый диапазон 0 - 8. Если 0, это означает, что framelist должен быть обновлен в конце передачи.
`frameList`	Указатель на массив структур IOUSBLowLatencyIsocFrame, описывающих кадры.
`callback`	Метод IOAsyncCallback1. Сообщение, адресуемое этому обратному вызову, добавлено к Асинхронному порту после завершения.
`refcon`	Произвольный указатель, передающийся в качестве параметра подпрограмме обратного вызова.

Возвращаемое значение

Возвраты kIOReturnSuccess в случае успеха, kIOReturnNoDevice, если нет никакого соединения с IOService или kIOReturnNotOpen, если интерфейс не открыт для эксклюзивного доступа. Если буфер или frameList не были ранее выделены с помощью LowLatencyCreateBuffer (), возвратит kIOUSBLowLatencyBufferNotPreviouslyAllocated или kIOUSBLowLatencyFrameListNotPreviouslyAllocated.

Обсуждение

LowLatencyReadIsochPipeAsync () и LowLatencyWriteIsochPipeAsync () вызовы походят на ReadIsochPipeAsync () и WriteIsochPipeAsync (). Они отличаются по этому, данные списка кадра обновляются в основное время прерывания. Это означает, что клиент может проверить frStatus и frActCount поля, как только транзакция завершается, не имея необходимость ожидать обратного вызова для случая (в зависимости от значения updateFrequency). Когда все кадры будут приняты, обратный вызов все еще произойдет.

Клиент может указать, как часто штабель USB должен обновить данные списка кадра путем указания updateFrequency: это значение может колебаться от 0 - 8. Если значение будет между 1 и 8, то список кадра будет обновлен каждый updateFrequency миллисекунды. Если значение будет 0, то список кадра будет только обновлен, как только были приняты все кадры в передаче. Например, считайте передачу с numFrames равной 64. Если частота обновления будет равняться 4, то данные списка кадра будут обновлены каждые 4 миллисекунды. Если частота обновления будет 0, то список кадра будет только обновлен в конце передачи, после того, как 64 кадра были переданы или получены. Различие между использованием частоты обновления 0 и использованием ненизкой задержки isoch вызовы - то, что в прежнем случае, список кадра будет обновлен в основное время прерывания, в то время как в последнем, это будет обновлено во вторичное время прерывания. Независимо от значения updateFrequency список кадра будет всегда обновляться на последнем кадре передачи.

Объяснение для добавления этого вызова - то, что, потому что подпрограммы завершения работают на USB Workloop, они, как могут планировать, выполнят много миллисекунд после того, как закончилась передача USB. Эта задержка является переменной и зависит от того, что другие более высокие приоритетные потоки работают на системе. Эта задержка представляет проблему для приложений, таких как обработка аудиоданных, которые зависят от получения данных, обработки его и передачи обратно его, и должны сделать это максимально быстро. Так как приложения, использующие изохронные данные, знают, когда данные должны быть доступными, они могут смотреть на список кадра в ожидаемое время и отметить frActCount и frStatus (и frTimeStamp в случае необходимости) и определить, сколько допустимых байтов находится в своем буфере данных и была ли ошибка. Они могут тогда получить доступ к своему буферу данных и обработать фактические данные.

Для обновления списка кадра в основное время прерывания и позволить клиенту видеть, что обновление, список кадра буферизует, должен быть совместно использован ядром и пространством пользователя. Та же вещь применяется к буферу данных. Это - различие между низкой задержкой isoch вызовы и регулярными вызовами isoch. LowLatencyCreateBuffer () вызов используется, чтобы предварительно выделить буферы. Клиент должен использовать тот вызов для выделения данных и буферов списка кадра. Клиент может передать часть ранее выделенного буфера. Штабель USB будет проверка диапазона данные и структурировать буферы списка, чтобы удостовериться, что они в диапазонах буферов, ранее выделенных. Это позволяет клиенту, если это так желает, для выделения большого буфера данных и частей передачи его к вызовам записи или чтению. То же применяется к буферам списка кадра. Конечно, клиент может также предварительно выделить несколько буферов данных и несколько буферов списка кадра и использовать тех для каждой передачи. Как только передача завершается, буферы могут быть снова использованы в последующих вызовах. Когда все передачи закончены, клиент должен вызвать LowLatencyDestroyBuffer () для каждого буфера, создававшегося с LowLatencyCreateBuffer ().

Интерфейс должен быть открыт для канала для существования. buf указатель и frameList указатель должны быть предварительно выделены с помощью LowLatencyCreateBuffer (). После использования их они должны быть освобождены с помощью LowLatencyDestroyBuffer ().


    
    LowLatencyWriteIsochPipeAsync
    - LowLatencyWriteIsochPipeAsync

Выполняет асинхронную запись на изохронном канале и обновляет список кадра в основное время прерывания.

Объявление

C++

IOReturn ( *LowLatencyWriteIsochPipeAsync)( void *self, UInt8 pipeRef, void *buf, UInt64 frameStart, UInt32 numFrames, UInt32 updateFrequency, IOUSBLowLatencyIsocFrame *frameList, IOAsyncCallback1 callback, void *refcon);

Параметры

`self`	Указатель на IOUSBInterfaceInterface.
`pipeRef`	Индекс для желаемого канала (1 - GetNumEndpoints).
`buf`	Буфер для содержания данных, ранее выделенных с LowLatencyCreateBuffer () использование типа kUSBLowLatencyWriteBuffer.
`frameStart`	Число кадра шины, на котором можно запустить запись (полученный из GetBusFrameNumber).
`numFrames`	Число кадров, для которых можно передать данные.
`updateFrequency`	Указывает, как часто, в миллисекундах, должен данные списка кадра быть обновленным. Допустимый диапазон 0 - 8. Если 0, это означает, что framelist должен быть обновлен в конце передачи.
`frameList`	Указатель на массив структур IOUSBLowLatencyIsocFrame, описывающих кадры.
`callback`	Метод IOAsyncCallback1. Сообщение, адресуемое этому обратному вызову, добавлено к Асинхронному порту после завершения.
`refcon`	Произвольный указатель, передающийся в качестве параметра подпрограмме обратного вызова.

Возвращаемое значение

Возвраты kIOReturnSuccess в случае успеха, kIOReturnNoDevice, если нет никакого соединения с IOService или kIOReturnNotOpen, если интерфейс не открыт для эксклюзивного доступа. Если буфер или frameList не были ранее выделены с помощью LowLatencyCreateBuffer (), возвратит kIOUSBLowLatencyBufferNotPreviouslyAllocated или kIOUSBLowLatencyFrameListNotPreviouslyAllocated.

Обсуждение

LowLatencyReadIsochPipeAsync () и LowLatencyWriteIsochPipeAsync () вызовы походят на ReadIsochPipeAsync () и WriteIsochPipeAsync (). Они отличаются по этому, данные списка кадра обновляются в основное время прерывания. Это означает, что клиент может проверить frStatus и frActCount поля, как только транзакция завершается, не имея необходимость ожидать обратного вызова для случая (в зависимости от значения updateFrequency). Когда все кадры будут приняты, обратный вызов все еще произойдет.

Клиент может указать, как часто штабель USB должен обновить данные списка кадра путем указания updateFrequency: это значение может колебаться от 0 - 8. Если значение будет между 1 и 8, то список кадра будет обновлен каждый updateFrequency миллисекунды. Если значение будет 0, то список кадра будет только обновлен, как только были приняты все кадры в передаче. Например, считайте передачу с numFrames равной 64. Если частота обновления будет равняться 4, то данные списка кадра будут обновлены каждые 4 миллисекунды. Если частота обновления будет 0, то список кадра будет только обновлен в конце передачи, после того, как 64 кадра были переданы или получены. Различие между использованием частоты обновления 0 и использованием ненизкой задержки isoch вызовы - то, что в прежнем случае, список кадра будет обновлен в основное время прерывания, в то время как в последнем, это будет обновлено во вторичное время прерывания. Независимо от значения updateFrequency список кадра будет всегда обновляться на последнем кадре передачи.

Объяснение для добавления этого вызова - то, что, потому что подпрограммы завершения работают на USB Workloop, они, как могут планировать, выполнят много миллисекунд после того, как закончилась передача USB. Эта задержка является переменной и зависит от того, что другие более высокие приоритетные потоки работают на системе. Эта задержка представляет проблему для приложений, таких как обработка аудиоданных, которые зависят от получения данных, обработки его и передачи обратно его, и должны сделать это максимально быстро. Так как приложения, использующие изохронные данные, знают, когда данные должны быть доступными, они могут смотреть на список кадра в ожидаемое время и отметить frActCount и frStatus (и frTimeStamp в случае необходимости) и определить, сколько допустимых байтов находится в своем буфере данных и была ли ошибка. Они могут тогда получить доступ к своему буферу данных и обработать фактические данные.

Для обновления списка кадра в основное время прерывания и позволить клиенту видеть, что обновление, список кадра буферизует, должен быть совместно использован ядром и пространством пользователя. Та же вещь применяется к буферу данных. Это - различие между низкой задержкой isoch вызовы и регулярными вызовами isoch. LowLatencyCreateBuffer () вызов используется, чтобы предварительно выделить буферы. Клиент должен использовать тот вызов для выделения данных и буферов списка кадра. Клиент может передать часть ранее выделенного буфера. Штабель USB будет проверка диапазона данные и структурировать буферы списка, чтобы удостовериться, что они в диапазонах буферов, ранее выделенных. Это позволяет клиенту, если это так желает, для выделения большого буфера данных и частей передачи его к вызовам записи или чтению. То же применяется к буферам списка кадра. Конечно, клиент может также предварительно выделить несколько буферов данных и несколько буферов списка кадра и использовать тех для каждой передачи. Как только передача завершается, буферы могут быть снова использованы в последующих вызовах. Когда все передачи закончены, клиент должен вызвать LowLatencyDestroyBuffer () для каждого буфера, создававшегося с LowLatencyCreateBuffer ().

Интерфейс должен быть открыт для канала для существования. buf указатель и frameList указатель должны быть предварительно выделены с помощью LowLatencyCreateBuffer (). После использования их они должны быть освобождены с помощью LowLatencyDestroyBuffer ().

IOUSBInterfaceInterface192

Прочие условия

Объявление

Параметры

Возвращаемое значение

Обсуждение

Объявление

Параметры

Возвращаемое значение

Обсуждение

Объявление

Параметры

Возвращаемое значение

Обсуждение

Объявление

Параметры

Возвращаемое значение

Обсуждение