2017-06-27 5 views
0

J'utilise libusb pour obtenir des données en temps réel à partir d'un périphérique audio USB. Ma taille de paquet maximum est de 196 octets. Je sais que 4 de ces octets sont ajoutés pour la somme de contrôle. Je veux identifier les octets utilisés pour la somme de contrôle afin que je puisse stocker seulement les données utiles du transfert mais j'ai quelques doutes:Comment identifier les octets de données utilisés pour CRC (checksum) dans un transfert ISO USB?

1) Ces octets sont-ils ajoutés au début ou à la fin du paquet?

2) Ces octets ont-ils une valeur réservée?

3) En cas de perte d'octets de données dans le transfert. Quelles considérations dois-je utiliser pour les octets utilisés pour la somme de contrôle?

EDIT 1

je ces doutes parce que mon dispositif spécifique a une interface et alt-cadre qui fonctionne avec une fréquence d'échantillonnage de 48 kHz, 2 canaux, profondeur 16 bits et avec un maximum de paquet Taille de 196 octets .

Donc, il y a 48 échantillons * 2 de deux canaux * 2 octets = 192 octets

Alors mes paquets devraient être de 192 octets, mais quand je mets mon appareil à travailler avec cette interface et alt-cadre Je commence pour recevoir des paquets de 196 octets. L'interface correspondante et le paramètre alt pour le point de sortie OUT ISO fonctionnent à une fréquence d'échantillonnage de 48 kHz, 2 canaux, 16 bits de profondeur et avec une taille de paquet maximale de 192 octets.

4) Si ces octets ne proviennent pas de la somme de contrôle, pourquoi ces octets sont-ils ajoutés?

+0

Vous devriez être en mesure d'obtenir cette information de la spécification du protocole. Si vous n'en avez pas, vous devrez l'inverser. –

Répondre

1

enter image description here

Je sais que 4 octets qui sont ajoutés pour la somme de contrôle

Mauvais. CRC est 2 octets pour le paquet de données et 5 bits pour le paquet de jetons. CRC n'est jamais stocké/retransmis dans/dans le tampon utilisateur. Il est déshabillé par le contrôleur lors de la vérification du CRC. Donc, vous n'allez pas voir le CRC du tout. Mais si vous voulez toujours voir le CRC, attachez un analyseur de paquets USB et jetez un oeil à la trace.

1) Sont ces octets ajoutés au début ou à la fin du paquet?

2 octets sont ajoutés à la fin.

2) Ces octets ont-ils une valeur réservée?

No. Son calculé en fonction du contenu du paquet de données

3) En cas de perdre quelques octets de données dans le transfert. Quelles considérations dois-je utiliser pour les octets utilisés pour la somme de contrôle?

Si vous perdez quelques octets après CRC est déjà calculé, vous allez obtenir une erreur de transaction USB (CRC mismatch de l'hôte). La même transaction sera réessayée par l'hôte.

PS - Je suppose que vous utilisez dispositif à grande vitesse

+0

Je sais que 16 bits sont utilisés pour le CRC mais je pense que je reçois 4 octets parce que je reçois des données pour un point de terminaison stéréo isochrone. Donc, 2 octets proviennent du premier canal et les deux autres octets proviennent du deuxième canal. – DrCachetes

+0

Ok, vous avez compris, mais le contrôleur CRC utilise votre CRC pour la vérification et, en fonction du résultat, il décidera s'il faut le considérer comme un bon ou un mauvais paquet. Si son bon paquet, l'hôte stockera les données dans le descripteur de transfert (EHCI) ou l'anneau de transfert (XHCI). Donc, aucun CRC n'est stocké dans votre tampon. – Shaibal

+0

Aussi je pense que 2 octets d'un canal et 2 octets de l'autre seront emballés dans un paquet de données et envoyés à travers le lien. Le CRC est par paquet et non par canal. En fin de compte, son seul point de terminaison envoie un paquet à la fois. Donc un CRC par paquet de données. – Shaibal