Audio data format after codec

I have got simple question about sample format after codec. I have to implement simple guitar distortion project and I have alghorithm which need data from codec in fixed point <-1,1> and my question is what is the format that I receive from codec and how to convert it to fixed point?

I use BF561 example project called: Audio Codec Talkthrough - TDM (C) and there I want to make changes to suit this tamplate to my needs.

Data format there is INT but how to convert it in simple way to fixed point?

Don't allow the compiler data type to confuse you. The int data type simply means that the data width is 32-bit, not that it is an integer. In compiler-speak for the Blackfin processors, int and long are interchangeable and refer to 32-bit data, whereas short is 16-bit data.

The DSP expects that the data it is operating on is fractional [-1, 1) (what you called fixed point above), and the buffer is declared as an int to support the 24-bit data that is being programmed to the ADC_CONTROL_2 register. If you look through the header files, you'll see typedefs to support 16-bit fractional data (fract16) and 32-bit fractional data (fract32), but these are simply reusing the long and short data types, respectively.

This all said, I think the answer to your question regarding the format of the data coming out of the codec is best answered by this related post:

Don't allow the compiler data type to confuse you. The int data type simply means that the data width is 32-bit, not that it is an integer. In compiler-speak for the Blackfin processors, int and long are interchangeable and refer to 32-bit data, whereas short is 16-bit data.

The DSP expects that the data it is operating on is fractional [-1, 1) (what you called fixed point above), and the buffer is declared as an int to support the 24-bit data that is being programmed to the ADC_CONTROL_2 register. If you look through the header files, you'll see typedefs to support 16-bit fractional data (fract16) and 32-bit fractional data (fract32), but these are simply reusing the long and short data types, respectively.

This all said, I think the answer to your question regarding the format of the data coming out of the codec is best answered by this related post: