Bug? Sound support for at91sam9x5-wm8731 based boards

Bug? Sound support for at91sam9x5-wm8731 based boards

[Zhong Li]

When playing stereo sound on the Atmel at91sam9x5-ek board the left and
right channel would get swapped about 1 in 6 tries.

Re: Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

2013/11/19 Zhong Li <zql@glomationinc.com>:
> When playing stereo sound on the Atmel at91sam9x5-ek board the left and
> right channel would get swapped about 1 in 6 tries.

Can you give a little more background ? :
- What kernel ?
- Command line to reproduce ?

Richard.

RE: [alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Zhong Li]

> Can you give a little more background ? :
> - What kernel ?
> - Command line to reproduce ?
> 
> Richard.

One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board).  We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc.  The command to test the sound is just the simple aplay <sound-test-file>.  The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing.

Thanks

Re: Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

[added Nicolas Ferre and Bo Shen ]

2013/11/19 Zhong Li <zql@glomationinc.com>:
>> Can you give a little more background ? :
>> - What kernel ?
>> - Command line to reproduce ?
>>
>> Richard.
>
> One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board).  We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc.  The command to test the sound is just the simple aplay <sound-test-file>.  The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing.
>
> Thanks

Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel

So, *sometimes*,  the left and right channel are swapped. ( I found
also the ratio 1 out of 6 (but once it has happened, it seems to be
more often))
I tested that with the file given by Zhong Li, and with a file I
created with audacity (440Hz only on right channel).
I could see at the scope that the channels are swapped before the
w8731 codec (the data on the TD line are sometime on the low edge of
TF, instead of always being on the high edge (I2S mode)).
There's, in both cases, a clock period (TK) between the rising/falling
edge of TF and the 1st data bit on TD, so the mode is always I2S, and
the channel data are swapped.

I'll try to have a look (but I don't have much time right now)

If someone could test that on a sam9g20 or a WM8904 based board, since
they share the same DAI format, they may have the same problem.

Thanks !
Richard

-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?

Re: [alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

2013/11/20 Richard Genoud <richard.genoud@gmail.com>:
> [added Nicolas Ferre and Bo Shen ]
>
> 2013/11/19 Zhong Li <zql@glomationinc.com>:
>>
>> One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board).  We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc.  The command to test the sound is just the simple aplay <sound-test-file>.  The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing.
>>
>> Thanks
>
> Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel
>
> So, *sometimes*,  the left and right channel are swapped. ( I found
> also the ratio 1 out of 6 (but once it has happened, it seems to be
> more often))
> I tested that with the file given by Zhong Li, and with a file I
> created with audacity (440Hz only on right channel).
> I could see at the scope that the channels are swapped before the
> w8731 codec (the data on the TD line are sometime on the low edge of
> TF, instead of always being on the high edge (I2S mode)).
> There's, in both cases, a clock period (TK) between the rising/falling
> edge of TF and the 1st data bit on TD, so the mode is always I2S, and
> the channel data are swapped.
>
> I'll try to have a look (but I don't have much time right now)
>
> If someone could test that on a sam9g20 or a WM8904 based board, since
> they share the same DAI format, they may have the same problem.

After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I
don't understand how the right and left channel are synchronized.
(which one will be on TF rising edge, and which one on TF falling edge
?)
In the SSC_TCMR register, the start event is TF_FALLING when there
only one channel (i.e. mono source always on left channel)
With a stereo source, it's TF_EDGE (Detection of any edge on TF
signal) ; so the samples are transferred on rising and falling edge.
I didn't see anything in the SSC what could synchronize the first
sample with a TF falling edge.
Or I missed something ?

Nicolas, Bo, any idea ?

Richard.

RE: [alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Zhong Li]

> 
> After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I
> don't understand how the right and left channel are synchronized.
> (which one will be on TF rising edge, and which one on TF falling edge
> ?)
> In the SSC_TCMR register, the start event is TF_FALLING when there only
> one channel (i.e. mono source always on left channel) With a stereo
> source, it's TF_EDGE (Detection of any edge on TF
> signal) ; so the samples are transferred on rising and falling edge.
> I didn't see anything in the SSC what could synchronize the first
> sample with a TF falling edge.
> Or I missed something ?
> 


The codec seems to be set to I2S mode based on the parameter name.  And the FSOS field in the TFMR is set to be negative pulse.  So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet).  The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data.  Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings.

Re: Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

2013/11/20 Zhong Li <zql@glomationinc.com>:
>>
>> After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I
>> don't understand how the right and left channel are synchronized.
>> (which one will be on TF rising edge, and which one on TF falling edge
>> ?)
>> In the SSC_TCMR register, the start event is TF_FALLING when there only
>> one channel (i.e. mono source always on left channel) With a stereo
>> source, it's TF_EDGE (Detection of any edge on TF
>> signal) ; so the samples are transferred on rising and falling edge.
>> I didn't see anything in the SSC what could synchronize the first
>> sample with a TF falling edge.
>> Or I missed something ?
>>
>
>
> The codec seems to be set to I2S mode based on the parameter name.  And the FSOS field in the TFMR is set to be negative pulse.  So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet).  The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data.  Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings.

Yes, we use the I2S mode as in wm8731-figure27.
But the WM8731 is in master mode (wm8731-figure3). So it provides BCLK
(TK) and frame clock (DACLRC (TF)).
That's set in sam9x5_wm8731.c :
dai->dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBM_CFM;
DAIFMT_I2S : I2S mode obviously (wm8731 reg 7 bit 0:1 = 2)
DAIFMT_NB_NF : clock frames phasing (wm8731 reg7 bit4=0, bit7=0 : Left
channel when DAC is low and BCKL not inverted)
DAIFMT_CBM_CFM : master mode (wm8731 reg7 bit6=1 )

And I think you read the wrong value for the FSOS field of TFMR
register : in the I2S + CBM_CFM case, it's set to 0 because TF pin is
an input for the SSC.

So yes, the wm8731 generates the TK and TF signals and the SSC is
configured to send 16bits data on every TF edge (SSC_START_EDGE_RF).
The SSC_FSEDGE_POSITIVE flag will trigger the TXSYN interrupt on a TF
positive edge.
That's a way to get the sync between right/left channel I think :
If we set SSC_FSEDGE_POSITIVE, and enable the TXSYN interrupt, at the
first interrupt received we could start the DMA transfer (and disable
the interrupt).
The SSC will then send the 1st data (left data) on the next TF edge
which will be a negative edge (left channel).

Richard