Typy danych i rozmiar buforów w pdm2pcm - akwizycja dźwięku

[radek04]

Cześć,

przeprowadzam akwizycję dźwięku z 4 mikrofonów MP34DT01-M przy użyciu interfejsu SAI oraz biblioteki pdm2pcm na STM32H743.

1. Moje pierwsze pytanie dotyczy typów zmiennych użytych w buforach PDM i PCM. Dane z 4 mikrofonów zapisuję w 32-bitowych slotach (po 8 bitów na mikrofon) w każdej ramce.

Obecnie wygląda to u mnie tak:

#define PDM_buffer_size 4096*4*6 //szóstka dobrana eksperymentalnie
#define PCM_buffer_size 4096*4 // równy output_samples_number

uint32_t PDM_buffer[PDM_buffer_size]; //bufor wejściowy PDM
uint16_t PCM_buffer[PCM_buffer_size]; //bufor wyjściowy PCM

HAL_SAI_Receive_DMA(&hsai_BlockA1, (uint8_t*)PDM_buffer, PDM_buffer_size); //rozpoczęcie akwizycji

PDM_Filter(&(((uint8_t*)PDM_buffer)[0]), &(((uint16_t*)PCM_buffer)[0]), &PDM1_filter_handler); //konwersja PDM na PCM mikrofon A
PDM_Filter(&(((uint8_t*)PDM_buffer)[1]), &(((uint16_t*)PCM_buffer)[1]), &PDM2_filter_handler); //konwersja PDM na PCM mikrofon B
PDM_Filter(&(((uint8_t*)PDM_buffer)[2]), &(((uint16_t*)PCM_buffer)[2]), &PDM3_filter_handler); //konwersja PDM na PCM mikrofon C
PDM_Filter(&(((uint8_t*)PDM_buffer)[3]), &(((uint16_t*)PCM_buffer)[3]), &PDM4_filter_handler); //konwersja PDM na PCM mikrofon D

Jednak deklaracja HAL_SAI_Receive_DMA wygląda następująco:

HAL_StatusTypeDef HAL_SAI_Receive_DMA(SAI_HandleTypeDef *hsai, uint8_t *pData, uint16_t Size)

Z jednej strony wskaźnik jest 8-bitowy, a rozmiar bufora 16-bitowy, a mój jest 32-bitowy.

Proszę o info, czy mam to dobrze.

 

2. Druga kwestia dotyczy rozmiaru użytych buforów. O ile PCM_buffer jest dość oczywisty i równy wartości output_samples_number (the number of samples by request) pomnożonej przez 4 mikrofony, o tyle z PDM_buffer mam już kłopot. Wartość dobrałem eksperymentalnie, aż zadziałało, natomiast nie mam pojęcia, dlaczego z tą szóstką już działa, a np. z czwórką nie.  Korzystam z decimation ratio równym 64.

 

3. Zgodnie z RM0433 str. 2254 dwie pierwsze ramki (zielona pętla) są nieprawidłowe. I o ile dla mikrofonu A mi się to sprawdza, o tyle dla pozostałych 3 mikrofonów pojawia się jeszcze jeden moment, w którym wartości są nieprawidłowe (na czerwono w załączonym pliku).

(Ten cały pierwszy przebieg 1-4096 pomijam w zapisie, więc to nie jest dla mnie problem, choć nie wiem, dlaczego tak dziwnie wygląda.)

Dodatkowo załączam wykres z wszystkich 4 mikrofonów, który w zasadzie powinien być jedną (pogrubioną) sinusoidą. Na tym wykresie kolejne wartości to odpowiednio próbki: A1,B1,C1,D1, A2,B2,C2,D2, A3,B3,C3,D3... Widać, że na początku każdego cyklu akwizycji (4*4096 próbek) następuje jakby przesunięcie w fazie. Na pierwszym wykresie zresztą też te nieprawidłowe wartości w czerwonej pętli wyglądają jak ucięta sinusoida i rozpoczęcie kolejnej w niewłaściwym miejscu.

Proszę o wszelkie pomysły i podpowiedzi, co mogę mieć źle, jaka jest przyczyna błędu lub jak jej zapobiec.

Na razie nie załączam kodu, ale jest on dość prosty i w czasie pojedynczego cyklu (4*4096) nie dzieje się nic poza akwizycją i konwersją.

Edytowano Maj 26, 2023 przez radek04