Questa pagina è stata tradotta dall'API Cloud Translation.

Limite per tipo di dispositivo

Nell'audio Android, viene utilizzato audio_devices_t per rappresentare il tipo di dispositivo audio. È ampiamente utilizzato nel codice sorgente audio come campo di bit per filtrare o selezionare uno o più specifici dei dispositivi. Prima di Android 11, era previsto un limite di 30 tipi di dispositivi di input/output audio e nessuno spazio libero per aggiungere nuovi tipi di dispositivi audio. Abbiamo rimosso il limite al numero di tipi di dispositivi audio per consentire nuovi tipi di dispositivi audio da aggiungere.

Per rimuovere il limite al numero di tipi di dispositivi audio, questi ora sono disponibili enumerati invece delle maschere di bit.

Tutti i tipi di dispositivi audio esistenti vengono mantenuti invariati. AUDIO_DEVICE_BIT_IN è ancora utilizzati per distinguere i dispositivi di input e di output. Quando aggiungi nuovi tipi di dispositivi audio, enumerati negli intervalli tra i valori esistenti.

Gli OEM non dovrebbero usare audio_devices_t come maschera di bit, perché questo può causare risultati imprevisti quando vengono aggiunti nuovi tipi di dispositivi audio enumerati.

Esempi e fonte

Prima di Android 11, erano due gli utilizzi tipici del dispositivo audio come le maschere di bit.

Utilizzo del valore audio_devices_t per rappresentare più dispositivi audio.
È in corso la verifica per verificare se il valore audio_devices_t contiene tipi di dispositivi audio di una categoria specificata.

Per rappresentare più tipi di dispositivi audio, una classe denominata DeviceTypeSet nel /libaudiofoundation/include/media/AudioContainers.h , che è un container std::set di audio_devices_t. La viene dichiarata nel libaudiofoundation. Per rappresentare più audio è possibile utilizzare tipi di dispositivi in codice C, un array o un elenco di audio_devices_t.

Per verificare se un singolo tipo di dispositivo appartiene a una categoria specificata, utilizza le funzioni helper audio_is_.*_device a /system/media/audio/include/system/audio.h. Per la custodia di più tipi di dispositivi audio, utilizza le funzioni helper in libaudiofoundation. Per Ad esempio, utilizza areAllOfSameDeviceType (DeviceTypeSet, std::function) tra AudioContainers.h per controllare se tutti i tipi di dispositivi audio specificati sono dello stesso tipo.

Implementazione

Gli OEM devono rimuovere la rappresentazione del campo di bit del tipo di dispositivo audio dall'implementazione dell'HAL audio.

Rimuovi tutti i dispositivi di archiviazione in un campo di bit.
L'elemento audio_devices_t non deve essere utilizzato per rappresentare più dispositivi audio di testo. Utilizza invece un elenco o un vettore.
Interrompi l'utilizzo delle operazioni a bit per il confronto tra tipi di dispositivi.
Prima di Android 11, i tipi di dispositivi audio potevano essere utilizzati come bitfield. In questo caso, è comune utilizzare operazioni a bit per i tipi di dispositivo. e i confronti. Quando vengono aggiunti nuovi tipi di dispositivi audio enumerati, le operazioni bit potrebbero causare risultati imprevisti. Puoi invece utilizzare le funzioni helper come alternativa. Se è presente un solo tipo di dispositivo audio, poi usa il confronto diretto per mettere a confronto i due valori. Per verificare se un audio dispositivo è di una categoria specificata, usa le funzioni helper in /system/media/audio/include/system/audio.h. Ad esempio: audio_is_output_device(audio_devices_t device).
Interrompi l'utilizzo dei valori predefiniti per gruppi di tipi di dispositivi audio.
Esistono alcuni valori predefiniti per gruppi di tipi di dispositivi audio, AUDIO_DEVICE_OUT_ALL, pollici system/media/audio/include/system/audio-base-utils.h. Tutti questi valori sono riservati, ma potrebbero essere deprecati in quanto non saranno corretti quando ne viene enumerato vengono aggiunti tipi di dispositivi audio. Esistono nuovi gruppi di tipi di dispositivi audio definiti in audio-base-utils.h, ovvero array di tipi di dispositivi audio, come AUDIO_DEVICE_OUT_ALL_ARRAY.
Implementa create_audio_patch() e release_audio_patch() per il routing invece di set_parameters.
Il metodo set_parameters utilizza tipi di dispositivi audio come campo di bit, quindi è possibile risultati imprevisti se vengono aggiunti nuovi tipi di dispositivi audio enumerati.

Attualmente sono richiesti due tipi di patch audio:
- Mixa con patch dispositivo, per la riproduzione
- Dispositivo per combinare patch per la registrazione
Negli aggiornamenti successivi, potrebbero essere necessarie patch aggiuntive da dispositivo a dispositivo.

Durante la creazione di una patch audio, se l'handle della patch non è specificato, è necessario l'HAL audio per generare un handle di patch univoco che possa a identificare la patch audio. Altrimenti, l'HAL audio deve usare l'handle della patch audio specificato per aggiornare la patch audio.

Se utilizzi un HAL audio precedente e il wrapper HIDL AOSP, devi impostare l'HAL audio precedente. la versione principale dell'HAL alla 3.0.

Per abilitare la funzionalità Patch audio, l'HAL audio deve impostare dalla versione principale dell'HAL alla 3.0 in alto. Consulta Device::supportsAudioPatches() in implementazione HIDL predefinita per ulteriori informazioni, disponibili anche nell'audio HAL per Seppia.

Personalizzazione

Non è possibile disattivare la funzione o ripristinare il refactoring dei dispositivi audio che consenta di aggiungere tipi di dispositivi audio.

Tutti i tipi di dispositivi audio aggiunti consentono di rappresentare un tipo di dispositivo con un singolo bit impostato. per cui le attuali implementazioni HAL continuano a funzionare.

Se vengono aggiunti nuovi tipi di dispositivi audio e gli OEM vogliono utilizzarli, devono devono eseguire l'upgrade dell'implementazione audio HAL e passare alla versione HIDL 6.0 o successiva. È obbligatorio per eseguire l'upgrade della versione principale dell'HAL alla 3.0 e implementare create_audio_patch e release_audio_patch, perché l'uso di set_parameters per indirizzare lo stream può causare risultati imprevisti quando vengono aggiunti nuovi tipi di dispositivi audio.

Convalida

Per gli OEM, il lavoro richiesto è aggiornare le implementazioni dell'HAL. VTS per l'audio HAL può essere utilizzato per verificare se l'implementazione funziona come previsto. Tutti i test sono disponibili nel File VTS.