adv7611 audio stream to iMX6

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

adv7611 audio stream to iMX6

Jump to solution
1,683 Views
alexandreur
Contributor II

Hi.

I am connecting ADV7611 to iMX6Q under Linux kernel 3.14.

The video part is fine.

But I have a trouble with audio.

When I try to record the input audio I hear silence only. Nothing else happens.

No error messages etc. Silence only.

There were error before I went to the current settings shown below but they are now eliminated and I have no further idea what to do.

Since the chip generates 32 bit per channel as documented in the UG-180.pdf, pages 54-57 (main doc on ADV7611. also see the attached screenshot) but iMX6 cannot receive 32 bit data.

I suspect mismatch of word length.

What must I do to fix it?

Is it possible to extract 24 or 16 most significant bits from the 32-bit source stream without changing the input format?

How to program the SRCR and SRCCR registers correctly?

Or must I pay attention on other things? Which?

There is output from my adv driver showing content of audio registers:

adv7611 2-004c: Audio: pll locked, samples detected, enabled
adv7611 2-004c: Audio format: stereo
adv7611 2-004c: Audio CTS: 74250
adv7611 2-004c: Audio N: 6144
adv7611 2-004c: AV Mute: off

These CTS and N correspond to 48 kHz stream

the adv7611 connects to AUDMUX4_RXFS, _RXC, _RXD

since adv7611 is master and connections are made to Rxxx signals I decided to use the async mode

now part of DTS

&ssi1 {
fsl,mode = "i2s-slave";
fsl,ssi-asynchronous;
status = "okay";
};

/ {
sound_mydriver:mydriver {
compatible = "my,mydriver";
model = "mydriver-audio";
cpu-dai = <&ssi1>;
mux-int-port = <1>;
mux-ext-port = <4>;
};
};

.....

MX6QDL_PAD_DISP0_DAT18__AUD4_RXFS 0x130b0
MX6QDL_PAD_DISP0_DAT19__AUD4_RXC 0x130b0
MX6QDL_PAD_DISP0_DAT23__AUD4_RXD 0x130b0

.....

so AUDMUX ports are programmed 

int=0 ptcr/pdcr=def7b000 00006000

ext=3 ptcr/pdcr=00000000 00000000

now output from debugfs

port 1 (number 0 by API)

PDCR: 00006000
PTCR: def7b000
TxFS output from RxFS3, TxClk output from RxClk3
RxFS output from RxFS3, RxClk output from RxClk3
Data received from 3

port 4 (number 3 by API)

PDCR: 00000000
PTCR: 00000000
TxFS input, TxClk input
RxFS input, RxClk input
Data received from 0

part of my driver code about DAI settings

data->dai.name = "Mydriver HiFi";
data->dai.stream_name = "Mydriver HiFi stream";
data->dai.codec_dai_name = "snd-soc-dummy-dai";
data->dai.codec_name = "snd-soc-dummy";
data->dai.cpu_of_node = ssi_np;
data->dai.platform_of_node = ssi_np;
data->dai.capture_only = true;
data->dai.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM;

How to overcome the silence?

Thanks!

Alex.

Tags (3)
0 Kudos
1 Solution
1,090 Views
alexandreur
Contributor II

Igor, you have misinformed me. And I lost some time trying to make another hardware path of data flow.

32 bits were length of the data frame, of course.

Width of significant bits were 16 and/or 24 bits indeed.

I do not know what was the real cause of troubles but I got normal sound after I connected CLK/LRCLK to TXC and TXFS using sync mode instead of RXC and RXFS in async mode and fixed some weirdnesses in the iMX6 drivers.

View solution in original post

0 Kudos
4 Replies
1,090 Views
igorpadykov
NXP Employee
NXP Employee

Hi Alex

unfortunately SSI does not support 32bit word length and it is

not possible to extract 24 or 16 most significant bits from the 32-bit source stream.

SSI has only word length (8, 10, 12, 16, 18, 20, 22 or 24 bits).
ESAI supports up to 24-bit data in a 32-bit slot (left or right aligned).
SAI supports up to 32-bit data.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,091 Views
alexandreur
Contributor II

Igor, you have misinformed me. And I lost some time trying to make another hardware path of data flow.

32 bits were length of the data frame, of course.

Width of significant bits were 16 and/or 24 bits indeed.

I do not know what was the real cause of troubles but I got normal sound after I connected CLK/LRCLK to TXC and TXFS using sync mode instead of RXC and RXFS in async mode and fixed some weirdnesses in the iMX6 drivers.

0 Kudos
1,090 Views
igorpadykov
NXP Employee
NXP Employee

Hi Alex

probably this was some misunderstanding, as

 there is no such term "as 32 bits were length of the data frame",
because according to RM definitions every frame consists of several

words and every word consists of some number of bits.

Best regards
igor

0 Kudos
1,090 Views
alexandreur
Contributor II

When I am on support and newbies asks me using incorrect terms, my answer have three parts:

1) Information that the term is incorrect

2) Guesses what did they mean and explaining each variation. Also I make clear mentions there variations are guesses only.

3) Answer to each guessed variation.

Either one of the guesses is correct or the client will be able to clarify his question and ask again correctly.

Thank you.

0 Kudos