TAS2563: TAS2563: Register settings for 48kHz 24 bits - mono out, 2x stereo in (PDM) - Wrong Endianess

Part Number: TAS2563
Other Parts Discussed in Thread: PCA9555, TAS2X63EVM

Tool/software:

Hello again!

(https://e2e.ti.com/support/audio-group/audio/f/audio-forum/1328857/tas2563-register-settings-for-48khz-24-bits---mono-out-2x-stereo-in-pdm - sorry for the delay, we had to work on other things in the meantime)

I'm happy to say that we succeeded to implement the TAS2563 to our board. Audio playback and most other things are working fine. But we have troubles with the PDM mics:

For some reason, the byte order seems to be reversed. The attached file (test17.raw) is recorded as S16_LE, but if I open it in Audacity with the recorded settings, it is distorted. BUT: if i import it (Raw data) with

- Signed 16-bit PCM

- Big Endian (which obviously does not match to the recording

- 4 Channels

- 48000 Hz

everything is as expected and the Mics are working fine.

Of course, recorded .wav files are corrupted as well.

So, my question is: How can I correct the byte order of the recording? Is it a setting in PPC3, a register setting (regbin), an entry in the device tree or in the ALSA system?

Screenshots from Audacity:

Little Endian:

Big Endian:

The file test17.raw was recorded as following:

# tinymix set "TASDEVICE Profile id" 5
# arecord -t raw -c4 -fS16_LE -r 48000 -v nfsdrive/tas2563/audiore
cords/test17.raw --device="hw:0,0"
Recording raw data 'nfsdrive/tas2563/audiorecords/test17.raw' : Signed 16 bit Littl
e Endian, Rate 48000 Hz, Channels 4
Hardware PCM card 0 'DPP-LMB-AR Soundcard tas2563' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 4
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 1
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
appl_ptr : 0
hw_ptr : 0
Kind regards,
Christian
  • Hi Christian,

    I2S is a MSB first protocol, which makes Big Endian more practical. I think this bug is just an issue with audacity, and it needs to flip in order to decode the audio correctly. There is nothing in the device itself that could cause something like this.

    Best regards,
    Jeff McPherson

  • Hi Jeff McPherson,

    thank you for your reply.

    But if the data stream is correct and intended in this way, how do I record usual .wav files?

    If I record a file with the command arecord -f dat test.wav (equals to 16 bits 48000 Hz Stereo), I get a distorted file with wrong byte order.

    Here are my device tree settings:

    / {
    sound_tas2563: sound-tas2563 {
    status = "okay";
    compatible = "simple-audio-card";
    simple-audio-card,name = "DPP-LMB-AR Soundcard TAS2563";
    simple-audio-card,format = "i2s";
    simple-audio-card,bitclock-inversion;
    simple-audio-card,frame-master = <&tas2563cpu>;
    simple-audio-card,bitclock-master = <&tas2563cpu>;

    tas2563cpu: simple-audio-card,cpu {
    sound-dai = <&sai3>;
    system-clock-direction = "out";
    };

    simple-audio-card,codec {
    sound-dai = <&tas2563>;
    system-clock-direction = "in";
    };
    };
    };

    &sai3 {
    fsl,mode = "i2s-master";
    assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
    assigned-clock-rates = <12288000>;
    status = "okay";
    };

    &i2c3 {
    tas2563: tasdevice@4c {
    status = "okay";
    #sound-dai-cells = <0>;
    compatible = "ti,tas2563";
    reg = <0x4c>;
    reset-gpios = <&pca9555 7 GPIO_ACTIVE_LOW>;
    };
    };

    Kind regards,

    Christian

  • Hi Christian,

    I doubt this is a problem with the device tree. I think you've showed that the endian is the issue and this has nothing to do with the device itself.

    I've looped in our software team to see if they can comment on the driver and if it can be tweaked.

    Best regards,
    Jeff McPherson

  • Hi Christian,

    pls record wav file with format  S16_BE(Big Endian), not  S16_LE(Little Endian).

    Thanks

    Kevin

  • Hello Kevin,

    thank you for your reply!

    Would you please give me a hint how I can do that? If I enter

    # arecord -t raw -c4 -fS16_BE -r48000 -v test.raw --device="hw:0,0"

    or

    # arecord -c4 -fS16_BE -r48000 -v test.wav --device="hw:0,0"

    I get the message:

    Recording WAVE 'test.raw' : Signed 16 bit Big Endian, Rate 48000 Hz, Channels 4
    arecord: set_params:1352: Sample format non available
    Available formats:
    - S16_LE
    - S24_LE
    - S32_LE

    Kind regards,

    Christian

  • Could you add macro definition in tasdevice.h ?

    Original:

    #define TASDEVICE_FORMATS	(SNDRV_PCM_FMTBIT_S16_LE | \
    	SNDRV_PCM_FMTBIT_S20_3LE | \
    	SNDRV_PCM_FMTBIT_S24_3LE | \
    	SNDRV_PCM_FMTBIT_S24_LE | \
    	SNDRV_PCM_FMTBIT_S32_LE)

    Change to be:

    #define TASDEVICE_FORMATS	(SNDRV_PCM_FMTBIT_S16_LE | \
    	SNDRV_PCM_FMTBIT_S20_3LE | \
    	SNDRV_PCM_FMTBIT_S24_3LE | \
    	SNDRV_PCM_FMTBIT_S24_LE | \
    	SNDRV_PCM_FMTBIT_S32_LE | \
    	SNDRV_PCM_FMTBIT_S16_BE | \
    	SNDRV_PCM_FMTBIT_S24_BE | \
    	SNDRV_PCM_FMTBIT_S32_BE)

    Thanks

    Kevin

  • Hello Kevin,

    I changed the definitions in tasdevice.h (at Line 61) as you suggested.

    The command

    # arecord -t raw -f S16_BE -r 48000 -c 4 test.raw

    works. If I import it to audacity as raw data S16_LE 16bits 48 Khz, I get the microphone signals, surprisingly with the microphone signals on channel 1 and 3 instead 1 and 2 as expected.

    The command

    # arecord -f S16_BE -r 48000 -c 4 test.raw

    rejects with the message
    Recording WAVE 'test.raw' : Signed 16 bit Big Endian, Rate 48000 Hz, Channels 4
    arecord: begin_wave:2679: Wave doesn't support S16_BE format...

    Please correct me if I'm wrong, but isn't the origin of the issue that ALSA expects the data to be in S16_LE but receives it in S16_BE?

    It's a bit strange that I have to record with S16_BE settings to receive S16_LE data...

    Do you see a possibility to change either the driver or the ALSA configuration to match the endianess?

    King regards,

    Christian

  • Hi Christian

    S16_LE which should be correct, in our device, always MSB first, 

     "surprisingly with the microphone signals on channel 1 and 3 instead 1 and 2 as expected"

    The problem should be on TX slot length setting, which is 32bit not 16bit

    Pls share your registers dump

    Thanks

    Kevin

  • Hello Kevin,

    thank you for your answer!

    currently, I'm using the settings (ID 5) from tas2563-1amp-reg.json within the tas2781-linux-driver.

    please find the following files:

    recgcfg_list (cat regcfg_list):

    Conf 05: 05-pdm-rec-i2s-48kHz-32bit-tx-slot-0-1-mic-slot-3-ref

    block type:PRE_SHUTDOWN device idx = 0x00
    SINGLE BYTE:
    BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x0e
    block type:PRE_POWER_UP device idx = 0x01
    FIELD:
    BOOK0x00 PAGE0x01 REG0x02 MASK0x1e VALUE = 0x00
    SINGLE BYTE:
    BOOK0x00 PAGE0x00 REG0x06 VALUE = 0x09
    BOOK0x00 PAGE0x00 REG0x08 VALUE = 0x7e
    BOOK0x00 PAGE0x00 REG0x0c VALUE = 0x40
    BOOK0x00 PAGE0x00 REG0x0b VALUE = 0x42
    BOOK0x00 PAGE0x00 REG0x0d VALUE = 0x44
    BOOK0x00 PAGE0x00 REG0x30 VALUE = 0x99
    BOOK0x00 PAGE0x00 REG0x0a VALUE = 0x13
    BOOK0x00 PAGE0x00 REG0x41 VALUE = 0x06
    BOOK0x00 PAGE0x00 REG0x07 VALUE = 0x02
    BOOK0x00 PAGE0x00 REG0x42 VALUE = 0x18
    BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x00

    PAGE00-regdump:

    addr: 0x4c

    Chn0B0x00P0x00R0x00:0x00
    Chn0B0x00P0x00R0x01:0x00
    Chn0B0x00P0x00R0x02:0x0e
    Chn0B0x00P0x00R0x03:0x13
    Chn0B0x00P0x00R0x04:0xc6
    Chn0B0x00P0x00R0x05:0x22
    Chn0B0x00P0x00R0x06:0x09
    Chn0B0x00P0x00R0x07:0x02
    Chn0B0x00P0x00R0x08:0x7e
    Chn0B0x00P0x00R0x09:0x10
    Chn0B0x00P0x00R0x0a:0x13
    Chn0B0x00P0x00R0x0b:0x42
    Chn0B0x00P0x00R0x0c:0x40
    Chn0B0x00P0x00R0x0d:0x44
    Chn0B0x00P0x00R0x0e:0x05
    Chn0B0x00P0x00R0x0f:0x06
    Chn0B0x00P0x00R0x10:0x07
    Chn0B0x00P0x00R0x11:0x27
    Chn0B0x00P0x00R0x12:0x13
    Chn0B0x00P0x00R0x13:0x76
    Chn0B0x00P0x00R0x14:0x01
    Chn0B0x00P0x00R0x15:0x2e
    Chn0B0x00P0x00R0x16:0x60
    Chn0B0x00P0x00R0x17:0x0e
    Chn0B0x00P0x00R0x18:0x0c
    Chn0B0x00P0x00R0x19:0x00
    Chn0B0x00P0x00R0x1a:0xfc
    Chn0B0x00P0x00R0x1b:0xa6
    Chn0B0x00P0x00R0x1c:0xdf
    Chn0B0x00P0x00R0x1d:0xef
    Chn0B0x00P0x00R0x1e:0xff
    Chn0B0x00P0x00R0x1f:0x04
    Chn0B0x00P0x00R0x20:0x00
    Chn0B0x00P0x00R0x21:0x00
    Chn0B0x00P0x00R0x22:0x80
    Chn0B0x00P0x00R0x23:0x00
    Chn0B0x00P0x00R0x24:0x04
    Chn0B0x00P0x00R0x25:0x00
    Chn0B0x00P0x00R0x26:0x11
    Chn0B0x00P0x00R0x27:0x80
    Chn0B0x00P0x00R0x28:0x00
    Chn0B0x00P0x00R0x29:0xdc
    Chn0B0x00P0x00R0x2a:0x51
    Chn0B0x00P0x00R0x2b:0xd0
    Chn0B0x00P0x00R0x2c:0x7e
    Chn0B0x00P0x00R0x2d:0xda
    Chn0B0x00P0x00R0x2e:0x00
    Chn0B0x00P0x00R0x2f:0xa6
    Chn0B0x00P0x00R0x30:0x99
    Chn0B0x00P0x00R0x31:0x40
    Chn0B0x00P0x00R0x32:0x81
    Chn0B0x00P0x00R0x33:0x34
    Chn0B0x00P0x00R0x34:0x4b
    Chn0B0x00P0x00R0x35:0xa4
    Chn0B0x00P0x00R0x36:0x00
    Chn0B0x00P0x00R0x37:0x00
    Chn0B0x00P0x00R0x38:0x12
    Chn0B0x00P0x00R0x39:0x0c
    Chn0B0x00P0x00R0x3a:0xbe
    Chn0B0x00P0x00R0x3b:0x58
    Chn0B0x00P0x00R0x3c:0x58
    Chn0B0x00P0x00R0x3d:0x08
    Chn0B0x00P0x00R0x3e:0x10
    Chn0B0x00P0x00R0x3f:0x00
    Chn0B0x00P0x00R0x40:0x76
    Chn0B0x00P0x00R0x41:0x06
    Chn0B0x00P0x00R0x42:0x18
    Chn0B0x00P0x00R0x43:0xc0
    Chn0B0x00P0x00R0x44:0x10
    Chn0B0x00P0x00R0x45:0x21
    Chn0B0x00P0x00R0x46:0x00
    Chn0B0x00P0x00R0x47:0x51
    Chn0B0x00P0x00R0x48:0x2c
    Chn0B0x00P0x00R0x49:0x51
    Chn0B0x00P0x00R0x4a:0x60
    Chn0B0x00P0x00R0x4b:0x00
    Chn0B0x00P0x00R0x4c:0x00
    Chn0B0x00P0x00R0x4d:0x00
    Chn0B0x00P0x00R0x4e:0x00
    Chn0B0x00P0x00R0x4f:0x00
    Chn0B0x00P0x00R0x50:0x00
    Chn0B0x00P0x00R0x51:0x00
    Chn0B0x00P0x00R0x52:0x00
    Chn0B0x00P0x00R0x53:0x00
    Chn0B0x00P0x00R0x54:0x00
    Chn0B0x00P0x00R0x55:0x00
    Chn0B0x00P0x00R0x56:0x00
    Chn0B0x00P0x00R0x57:0x00
    Chn0B0x00P0x00R0x58:0x00
    Chn0B0x00P0x00R0x59:0x00
    Chn0B0x00P0x00R0x5a:0x00
    Chn0B0x00P0x00R0x5b:0x00
    Chn0B0x00P0x00R0x5c:0x00
    Chn0B0x00P0x00R0x5d:0x00
    Chn0B0x00P0x00R0x5e:0x00
    Chn0B0x00P0x00R0x5f:0x00
    Chn0B0x00P0x00R0x60:0x00
    Chn0B0x00P0x00R0x61:0x00
    Chn0B0x00P0x00R0x62:0x00
    Chn0B0x00P0x00R0x63:0x00
    Chn0B0x00P0x00R0x64:0x00
    Chn0B0x00P0x00R0x65:0x00
    Chn0B0x00P0x00R0x66:0x00
    Chn0B0x00P0x00R0x67:0x00
    Chn0B0x00P0x00R0x68:0x00
    Chn0B0x00P0x00R0x69:0x00
    Chn0B0x00P0x00R0x6a:0x00
    Chn0B0x00P0x00R0x6b:0x00
    Chn0B0x00P0x00R0x6c:0x00
    Chn0B0x00P0x00R0x6d:0x00
    Chn0B0x00P0x00R0x6e:0x00
    Chn0B0x00P0x00R0x6f:0x00
    Chn0B0x00P0x00R0x70:0x00
    Chn0B0x00P0x00R0x71:0x00
    Chn0B0x00P0x00R0x72:0x00
    Chn0B0x00P0x00R0x73:0xf0
    Chn0B0x00P0x00R0x74:0x00
    Chn0B0x00P0x00R0x75:0x0f
    Chn0B0x00P0x00R0x76:0x00
    Chn0B0x00P0x00R0x77:0x00
    Chn0B0x00P0x00R0x78:0x80
    Chn0B0x00P0x00R0x79:0x00
    Chn0B0x00P0x00R0x7a:0x00
    Chn0B0x00P0x00R0x7b:0x00
    Chn0B0x00P0x00R0x7c:0x00
    Chn0B0x00P0x00R0x7d:0x10
    Chn0B0x00P0x00R0x7e:0xb4
    Chn0B0x00P0x00R0x7f:0x00
    == == == caught smartpa reg end == == ==

    PAGE01-regdump

    addr: 0x4c

    Chn0B0x00P0x01R0x00:0x00
    Chn0B0x00P0x01R0x01:0x00
    Chn0B0x00P0x01R0x02:0x20
    Chn0B0x00P0x01R0x03:0x44
    Chn0B0x00P0x01R0x04:0x80
    Chn0B0x00P0x01R0x05:0x42
    Chn0B0x00P0x01R0x06:0x01
    Chn0B0x00P0x01R0x07:0x24
    Chn0B0x00P0x01R0x08:0x40
    Chn0B0x00P0x01R0x09:0x00
    Chn0B0x00P0x01R0x0a:0x52
    Chn0B0x00P0x01R0x0b:0x10
    Chn0B0x00P0x01R0x0c:0x48
    Chn0B0x00P0x01R0x0d:0x02
    Chn0B0x00P0x01R0x0e:0x68
    Chn0B0x00P0x01R0x0f:0x00
    Chn0B0x00P0x01R0x10:0x40
    Chn0B0x00P0x01R0x11:0x12
    Chn0B0x00P0x01R0x12:0x00
    Chn0B0x00P0x01R0x13:0x00
    Chn0B0x00P0x01R0x14:0x00
    Chn0B0x00P0x01R0x15:0x00
    Chn0B0x00P0x01R0x16:0x40
    Chn0B0x00P0x01R0x17:0x00
    Chn0B0x00P0x01R0x18:0x00
    Chn0B0x00P0x01R0x19:0x02
    Chn0B0x00P0x01R0x1a:0x00
    Chn0B0x00P0x01R0x1b:0x01
    Chn0B0x00P0x01R0x1c:0x08
    Chn0B0x00P0x01R0x1d:0x00
    Chn0B0x00P0x01R0x1e:0x00
    Chn0B0x00P0x01R0x1f:0x60
    Chn0B0x00P0x01R0x20:0x03
    Chn0B0x00P0x01R0x21:0x00
    Chn0B0x00P0x01R0x22:0x01
    Chn0B0x00P0x01R0x23:0x00
    Chn0B0x00P0x01R0x24:0x00
    Chn0B0x00P0x01R0x25:0x00
    Chn0B0x00P0x01R0x26:0x00
    Chn0B0x00P0x01R0x27:0x00
    Chn0B0x00P0x01R0x28:0x10
    Chn0B0x00P0x01R0x29:0x10
    Chn0B0x00P0x01R0x2a:0x02
    Chn0B0x00P0x01R0x2b:0x00
    Chn0B0x00P0x01R0x2c:0x20
    Chn0B0x00P0x01R0x2d:0x01
    Chn0B0x00P0x01R0x2e:0x09
    Chn0B0x00P0x01R0x2f:0x01
    Chn0B0x00P0x01R0x30:0x30
    Chn0B0x00P0x01R0x31:0x00
    Chn0B0x00P0x01R0x32:0x80
    Chn0B0x00P0x01R0x33:0x00
    Chn0B0x00P0x01R0x34:0x00
    Chn0B0x00P0x01R0x35:0x00
    Chn0B0x00P0x01R0x36:0x00
    Chn0B0x00P0x01R0x37:0x00
    Chn0B0x00P0x01R0x38:0x00
    Chn0B0x00P0x01R0x39:0x00
    Chn0B0x00P0x01R0x3a:0x00
    Chn0B0x00P0x01R0x3b:0x12
    Chn0B0x00P0x01R0x3c:0x48
    Chn0B0x00P0x01R0x3d:0x10
    Chn0B0x00P0x01R0x3e:0x10
    Chn0B0x00P0x01R0x3f:0x01
    Chn0B0x00P0x01R0x40:0x00
    Chn0B0x00P0x01R0x41:0x00
    Chn0B0x00P0x01R0x42:0x00
    Chn0B0x00P0x01R0x43:0x00
    Chn0B0x00P0x01R0x44:0x00
    Chn0B0x00P0x01R0x45:0x00
    Chn0B0x00P0x01R0x46:0x00
    Chn0B0x00P0x01R0x47:0x00
    Chn0B0x00P0x01R0x48:0x00
    Chn0B0x00P0x01R0x49:0x00
    Chn0B0x00P0x01R0x4a:0x00
    Chn0B0x00P0x01R0x4b:0x00
    Chn0B0x00P0x01R0x4c:0x00
    Chn0B0x00P0x01R0x4d:0x00
    Chn0B0x00P0x01R0x4e:0x00
    Chn0B0x00P0x01R0x4f:0x00
    Chn0B0x00P0x01R0x50:0x00
    Chn0B0x00P0x01R0x51:0x00
    Chn0B0x00P0x01R0x52:0x00
    Chn0B0x00P0x01R0x53:0x00
    Chn0B0x00P0x01R0x54:0x00
    Chn0B0x00P0x01R0x55:0x00
    Chn0B0x00P0x01R0x56:0x00
    Chn0B0x00P0x01R0x57:0x00
    Chn0B0x00P0x01R0x58:0x00
    Chn0B0x00P0x01R0x59:0x00
    Chn0B0x00P0x01R0x5a:0x00
    Chn0B0x00P0x01R0x5b:0x00
    Chn0B0x00P0x01R0x5c:0x00
    Chn0B0x00P0x01R0x5d:0x00
    Chn0B0x00P0x01R0x5e:0x00
    Chn0B0x00P0x01R0x5f:0x00
    Chn0B0x00P0x01R0x60:0x00
    Chn0B0x00P0x01R0x61:0x00
    Chn0B0x00P0x01R0x62:0x00
    Chn0B0x00P0x01R0x63:0x00
    Chn0B0x00P0x01R0x64:0x00
    Chn0B0x00P0x01R0x65:0x00
    Chn0B0x00P0x01R0x66:0x00
    Chn0B0x00P0x01R0x67:0x00
    Chn0B0x00P0x01R0x68:0x00
    Chn0B0x00P0x01R0x69:0x00
    Chn0B0x00P0x01R0x6a:0x00
    Chn0B0x00P0x01R0x6b:0x00
    Chn0B0x00P0x01R0x6c:0x00
    Chn0B0x00P0x01R0x6d:0x00
    Chn0B0x00P0x01R0x6e:0x00
    Chn0B0x00P0x01R0x6f:0x00
    Chn0B0x00P0x01R0x70:0x00
    Chn0B0x00P0x01R0x71:0x00
    Chn0B0x00P0x01R0x72:0x00
    Chn0B0x00P0x01R0x73:0x00
    Chn0B0x00P0x01R0x74:0x00
    Chn0B0x00P0x01R0x75:0x00
    Chn0B0x00P0x01R0x76:0x00
    Chn0B0x00P0x01R0x77:0x00
    Chn0B0x00P0x01R0x78:0x00
    Chn0B0x00P0x01R0x79:0x00
    Chn0B0x00P0x01R0x7a:0x00
    Chn0B0x00P0x01R0x7b:0x00
    Chn0B0x00P0x01R0x7c:0x00
    Chn0B0x00P0x01R0x7d:0x00
    Chn0B0x00P0x01R0x7e:0x00
    Chn0B0x00P0x01R0x7f:0x00
    == == == caught smartpa reg end == == ==

    Kind regards,

    Christian

  • Hello Kevin,

    as you didn't answer to my post from last week - do you see a chance to get the PDM microphone data to ALSA using your Linux driver?

    By the way: the issue concerning channel 1 and 3 in the previous post resulted from some alsa setting: I was playing around with the settings. Using S16_BE in the config file results having the data on channel 1 and 3 and S16_SE puts the data on channel 1 and 2 as expected.

    BUT: both and all other setting record the data in wrong byte order: recording with format S16_LE (arecord) results in data with S16_BE and vice versa - regardless of the settings in asound.conf - the only difference is the channel within the raw file.

    So, recording a simple .wav file currently is not possible.

    The setting for receiving data on channel 1 and 2, bit with wrong byte order, is following:

    pcm.test{
    type dsnoop
    ipc_key 123456
    slave {
    pcm "hw:0,0"
    channels 4
    format S16_LE
    rate 48000
    }
    }

    Recording data with >arecord -t raw -f S16_LE -r 48000 -c 4 filename.raw< and importing it to audacity with following settings results in usable audio data, but as you can see, the byte order does not match the settings in arecord. Therefore, audio record in Linux is not possible without very dirty hacking of the audio stream. Standard .wav files are corrupted.

    Looking forward to your professional support.

    Kind regards,

    Christian

  • Hi Christian,

    Sorry for delayed response since I was on vacation last week, I will transfer thread to Shenghao to answer.

    Thanks

    Kevin

  • Hi, Guy

    Kindly try setting B0P0R0xA:TX_OFFSET to 0, 2, 3, 4, 5, 6, 7

  • Hi, thanks for your answer.

    Just to make sure that I have understood you correctly:

    I should try the different settings 0x0, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7 in register B0P0R0xA:TX_OFFSET and see the differences?

  • Hello!

    I tried the different settings - TX_EDGE and TX_FILL (0x13, which was the previous setting) does not seem to make any difference. TX_OFFSET[2:0] seems to move the data backwards but does not change the byte order - with the effect to lower the signal if imported with BIG ENDIAN.

    The following pictures were recorded with

    arecord -t raw -f S16_LE -r 48000 -c 4 -d 2 filename.raw

    The first 4 channels show the raw file imported with LITTLE ENDIAN and channel 5 to 8 with BIG ENDIAN. The other importing settings the same as shown in the screenshot in one of the previous posts.

    0x0:

    0x2:

    0x3:

    0x4:

    0x5:

    0x6:

    0x7:

    0x13:

    Kind regards,

    Christian

  • Hi Guy,

    Thanks for your verification. kindly stop that trying.

    Can you upload the wav file with the default setting of TX_OFFSET?

    According to Chn0B0x00P0x00R0x11:0x27, it seemed that the samplerate is not detected, and bitwidth is 64-bit.

    Kindly measure both bck and ws clk with scope, ans share the waveform here.

    Also, kindly check the PMIC whether it have some setting for byte endian. 

    One more thing, the register dump you shared is not in working mode. kindly use following commands:

    arecord -t raw -f S16_LE -r 48000 -c 4 -d 2 filename.raw &   // & is to force the command to the background

    Then dump the book0page0 registers 

  • Hello,

    Thank you for your answer!

    Please find the requested files at https://www.demmel.com/nc/index.php/s/AGM5z3DzMSF9dZx

    The .zip archive contains the regdump (20240708_regdump_PAGE00.txt) while recording with including the corresponding .raw file

    arecord -t raw -f S16_LE -r 48000 -c 4 test_a13_regdump.raw -d 5

    a second file recordes as .wav recorded with

    arecord -f S16_LE -r 48000 -c 4 test_a13_regdump.wav -d 5

    and the regbin settings (regbin_a13.txt).

    We use two of the Infineon IM72D128V01 mics, but I didn't find any possibility to adjust the byte order - please find the datasheet here:

    https://www.infineon.com/dgdl/Infineon-IM72D128-DataSheet-v01_01-EN.pdf?fileId=8ac78c8c80027ecd0180612a60277e10

    The scope measurements will come with an additional post. Just to ensure: I2S bit clock: SBCLK1 (QFN pin 6) and I2S frame sync: FSYNC (QFN pin 5) on the TAS2563, correct?

    We are using the QFN package.

    Kind regards,

    Christian

  • Hello again,

    please find the scope images in various time resolutions.

    CH1 is SBCLK1, CH2 is FSYNC

    The measurements were taken during audio recording.

    Kind regards,

    Christian

  • Hi, Guy,

    1. try setting BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x70 before running arecord, if now work, then revert this setting, try next
    2. Can you try following command,  arecord -t raw -f S32_LE -r 48000 -c 2 test.raw & // attention: & can push arecord working in the background
    3. One more thing, kindly confirm whether PDM support Little Endian setting
    4. As to the register dump, the register dump you offered is not in working mode, b0p0r2=0xe. which clues tas2563 is power off. do not append & in your arecord command.

  • Hello,

    ad 1: I don't exactly understand your advise - what I did was:

    - write 0x70 to register 0x02 and record: no effect was shown

    - changing the regbin file - last entry of PRE_POWER_UP to BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x70: the effect was a little distortion (a little bit like jitter) on playback and the same on record, but nothing on endianess. I reverted this setting as you wrote. My current regbin settings are (as before):

    Conf 06: 06-pdm-rec

    block type:PRE_SHUTDOWN     device idx = 0x00
            SINGLE BYTE:
                BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x0e
                BOOK0x00 PAGE0x00 REG0x41 VALUE = 0x46
    block type:PRE_POWER_UP     device idx = 0x01
            FIELD:
                BOOK0x00 PAGE0x01 REG0x02 MASK0x1e VALUE = 0x00
            SINGLE BYTE:
                BOOK0x00 PAGE0x00 REG0x06 VALUE = 0x09
                BOOK0x00 PAGE0x00 REG0x08 VALUE = 0x7e
                BOOK0x00 PAGE0x00 REG0x0b VALUE = 0x40
                BOOK0x00 PAGE0x00 REG0x0c VALUE = 0x42
                BOOK0x00 PAGE0x00 REG0x0d VALUE = 0x44
                BOOK0x00 PAGE0x00 REG0x0a VALUE = 0x13
                BOOK0x00 PAGE0x00 REG0x30 VALUE = 0x99
                BOOK0x00 PAGE0x00 REG0x41 VALUE = 0x06
                BOOK0x00 PAGE0x00 REG0x42 VALUE = 0x18
                BOOK0x00 PAGE0x00 REG0x07 VALUE = 0x02
                BOOK0x00 PAGE0x00 REG0x02 VALUE = 0x00

    ad 2: You can find the file here: https://www.demmel.com/nc/index.php/s/DnxxeBonfcsGiSZ

    (still wrong byte order)

    ad 3: I cannot find any hint regarding any byte order in the datasheet of the PDM microphone - https://www.infineon.com/dgdl/Infineon-IM72D128-DataSheet-v01_01-EN.pdf?fileId=8ac78c8c80027ecd0180612a60277e10

    but: they worked using PPC3, your evaluation kit TAS2x63EVM and your Windows drivers. 

    ad 4: I added the regdump to the .zip file in the previous post stating  Chn0B0x00P0x00R0x02:0x00

    once again as text:

    addr: 0x4c

    Chn0B0x00P0x00R0x00:0x00
    Chn0B0x00P0x00R0x01:0x00
    Chn0B0x00P0x00R0x02:0x00
    Chn0B0x00P0x00R0x03:0x10
    Chn0B0x00P0x00R0x04:0xc6
    Chn0B0x00P0x00R0x05:0x22
    Chn0B0x00P0x00R0x06:0x09
    Chn0B0x00P0x00R0x07:0x02
    Chn0B0x00P0x00R0x08:0x7e
    Chn0B0x00P0x00R0x09:0x10
    Chn0B0x00P0x00R0x0a:0x13
    Chn0B0x00P0x00R0x0b:0x40
    Chn0B0x00P0x00R0x0c:0x42
    Chn0B0x00P0x00R0x0d:0x44
    Chn0B0x00P0x00R0x0e:0x05
    Chn0B0x00P0x00R0x0f:0x06
    Chn0B0x00P0x00R0x10:0x07
    Chn0B0x00P0x00R0x11:0x24
    Chn0B0x00P0x00R0x12:0x13
    Chn0B0x00P0x00R0x13:0x76
    Chn0B0x00P0x00R0x14:0x01
    Chn0B0x00P0x00R0x15:0x2e
    Chn0B0x00P0x00R0x16:0x60
    Chn0B0x00P0x00R0x17:0x0e
    Chn0B0x00P0x00R0x18:0x0c
    Chn0B0x00P0x00R0x19:0x00
    Chn0B0x00P0x00R0x1a:0xfc
    Chn0B0x00P0x00R0x1b:0xa6
    Chn0B0x00P0x00R0x1c:0xdf
    Chn0B0x00P0x00R0x1d:0xef
    Chn0B0x00P0x00R0x1e:0xff
    Chn0B0x00P0x00R0x1f:0x00
    Chn0B0x00P0x00R0x20:0x00
    Chn0B0x00P0x00R0x21:0x11
    Chn0B0x00P0x00R0x22:0x00
    Chn0B0x00P0x00R0x23:0x00
    Chn0B0x00P0x00R0x24:0x00
    Chn0B0x00P0x00R0x25:0x00
    Chn0B0x00P0x00R0x26:0x11
    Chn0B0x00P0x00R0x27:0x80
    Chn0B0x00P0x00R0x28:0x00
    Chn0B0x00P0x00R0x29:0x4c
    Chn0B0x00P0x00R0x2a:0x51
    Chn0B0x00P0x00R0x2b:0xd0
    Chn0B0x00P0x00R0x2c:0x79
    Chn0B0x00P0x00R0x2d:0xda
    Chn0B0x00P0x00R0x2e:0x00
    Chn0B0x00P0x00R0x2f:0xa3
    Chn0B0x00P0x00R0x30:0x99
    Chn0B0x00P0x00R0x31:0x40
    Chn0B0x00P0x00R0x32:0x81
    Chn0B0x00P0x00R0x33:0x34
    Chn0B0x00P0x00R0x34:0x4b
    Chn0B0x00P0x00R0x35:0xa4
    Chn0B0x00P0x00R0x36:0x00
    Chn0B0x00P0x00R0x37:0x00
    Chn0B0x00P0x00R0x38:0x12
    Chn0B0x00P0x00R0x39:0x0c
    Chn0B0x00P0x00R0x3a:0xbe
    Chn0B0x00P0x00R0x3b:0x58
    Chn0B0x00P0x00R0x3c:0x54
    Chn0B0x00P0x00R0x3d:0x08
    Chn0B0x00P0x00R0x3e:0x10
    Chn0B0x00P0x00R0x3f:0x00
    Chn0B0x00P0x00R0x40:0x76
    Chn0B0x00P0x00R0x41:0x06
    Chn0B0x00P0x00R0x42:0x18
    Chn0B0x00P0x00R0x43:0xc0
    Chn0B0x00P0x00R0x44:0x10
    Chn0B0x00P0x00R0x45:0x21
    Chn0B0x00P0x00R0x46:0x00
    Chn0B0x00P0x00R0x47:0x51
    Chn0B0x00P0x00R0x48:0x2c
    Chn0B0x00P0x00R0x49:0x51
    Chn0B0x00P0x00R0x4a:0x40
    Chn0B0x00P0x00R0x4b:0x03
    Chn0B0x00P0x00R0x4c:0x00
    Chn0B0x00P0x00R0x4d:0x00
    Chn0B0x00P0x00R0x4e:0x00
    Chn0B0x00P0x00R0x4f:0x00
    Chn0B0x00P0x00R0x50:0x00
    Chn0B0x00P0x00R0x51:0x00
    Chn0B0x00P0x00R0x52:0x00
    Chn0B0x00P0x00R0x53:0x00
    Chn0B0x00P0x00R0x54:0x00
    Chn0B0x00P0x00R0x55:0x00
    Chn0B0x00P0x00R0x56:0x00
    Chn0B0x00P0x00R0x57:0x00
    Chn0B0x00P0x00R0x58:0x00
    Chn0B0x00P0x00R0x59:0x00
    Chn0B0x00P0x00R0x5a:0x00
    Chn0B0x00P0x00R0x5b:0x00
    Chn0B0x00P0x00R0x5c:0x00
    Chn0B0x00P0x00R0x5d:0x00
    Chn0B0x00P0x00R0x5e:0x00
    Chn0B0x00P0x00R0x5f:0x00
    Chn0B0x00P0x00R0x60:0x00
    Chn0B0x00P0x00R0x61:0x00
    Chn0B0x00P0x00R0x62:0x00
    Chn0B0x00P0x00R0x63:0x00
    Chn0B0x00P0x00R0x64:0x00
    Chn0B0x00P0x00R0x65:0x00
    Chn0B0x00P0x00R0x66:0x00
    Chn0B0x00P0x00R0x67:0x00
    Chn0B0x00P0x00R0x68:0x00
    Chn0B0x00P0x00R0x69:0x00
    Chn0B0x00P0x00R0x6a:0x00
    Chn0B0x00P0x00R0x6b:0x00
    Chn0B0x00P0x00R0x6c:0x00
    Chn0B0x00P0x00R0x6d:0x00
    Chn0B0x00P0x00R0x6e:0x00
    Chn0B0x00P0x00R0x6f:0x00
    Chn0B0x00P0x00R0x70:0x00
    Chn0B0x00P0x00R0x71:0x00
    Chn0B0x00P0x00R0x72:0x00
    Chn0B0x00P0x00R0x73:0xf0
    Chn0B0x00P0x00R0x74:0x00
    Chn0B0x00P0x00R0x75:0x0f
    Chn0B0x00P0x00R0x76:0x00
    Chn0B0x00P0x00R0x77:0x00
    Chn0B0x00P0x00R0x78:0xcc
    Chn0B0x00P0x00R0x79:0x00
    Chn0B0x00P0x00R0x7a:0x00
    Chn0B0x00P0x00R0x7b:0x00
    Chn0B0x00P0x00R0x7c:0x00
    Chn0B0x00P0x00R0x7d:0x10
    Chn0B0x00P0x00R0x7e:0x64
    Chn0B0x00P0x00R0x7f:0x00
     == == == caught smartpa reg end == ==  ==

    Kind regards and thank you for your support,

    Christian

  • Hi Christian,

    Can you please share a scope capture of the SDOUT data along with FSYNC? This can be just for a few samples. I'd like to verify the data "shape" looks OK.
    In general, for TX or RX of data, MSB is always the left-most bit. There's some format configuration options, but that's limited to the ones below, there's no way to change MSB location:

    • Offset: this is how many empty bits are included in each slot, if any.
    • Justification: this is how the data bits are positioned in the slot, moving the offset bits (if any) to the opposite side.
    • I2S/TDM: this is how a frame starts with respect to FSYNC edge.

    If the data is coming out of the device as expected, then the problem must be on the way the data is then translated into wav format.

    Best regards,
    -Ivan Salazar
    Applications Engineer

  • Hello Ivan,

    thank you for your reply!

    Please find the requested captures (CH1: SBCLK1, CH2: FSYNC, CH3: DATA_SDOUT1):

    If this captures are as expected:

    Which element converts the data from I2S to .wav? Isn't the driver responsible for that conversion? At least, I don't know, where to have an influence to that conversion. (I already tried out some settings with S16_BE in alsa.conf, but without success). Is there any option to change the driver configuration e.g. in the device tree?

    We are using the driver from https://git.ti.com/cgit/tas2781-linux-drivers/tas2781-linux-driver/tree/ in combination with the simple-audio-card and the sai3 interface coming from the NXP BSP (kernel version 5.15.71). I've already posted our device tree and alsa.conf settings in previous messages.

    Kind regards,

    Christian

  • Hi Christian,

    Are these captures with PDM data running from the microphone? It seems almost all the bits are Hi?
    Can you try capturing SDOUT data again while holding PDMD both Hi and Lo?

    Best regards,
    -Ivan Salazar
    Applications Engineer