Issue on Linux 4.12-rc7 on iMX6 based board

Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

Hello list,

I have some issue using the sgtl5000 on two custom boards based with 
iMX6. One board has iMX6DL and the other has iMX6QP.

The issue is I have a (dramatically high) strange value on mixer 
settings (looks like a int32 limit or similar)

This is the output of amixer:
> # amixer
> Simple mixer control 'Headphone',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 127
>   Mono:
>   Front Left: Playback 0 [2147483647%] [-51.50dB] [on]
>   Front Right: Playback 0 [2147483647%] [-51.50dB] [on]
> Simple mixer control 'Headphone Mux',0
>   Capabilities: enum
>   Items: 'DAC' 'LINE_IN'
>   Item0: 'DAC'
> Simple mixer control 'Headphone Playback ZC',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [on]
> Simple mixer control 'PCM',0
>   Capabilities: pvolume
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 192
>   Mono:
>   Front Left: Playback 1 [2147483647%]
>   Front Right: Playback 0 [2147483647%]
> Simple mixer control 'Lineout',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 31
>   Mono:
>   Front Left: Playback 18 [2147483647%] [-6.50dB] [on]
>   Front Right: Playback 18 [2147483647%] [-6.50dB] [on]
> Simple mixer control 'Mic',0
>   Capabilities: volume volume-joined
>   Playback channels: Mono
>   Capture channels: Mono
>   Limits: 0 - 3
>   Mono: 0 [2147483647%] [0.00dB]
> Simple mixer control 'Capture',0
>   Capabilities: cvolume
>   Capture channels: Front Left - Front Right
>   Limits: Capture 0 - 15
>   Front Left: Capture 0 [2147483647%]
>   Front Right: Capture 0 [2147483647%]
> Simple mixer control 'Capture Attenuate Switch (-6dB)',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [off]
> Simple mixer control 'Capture Mux',0
>   Capabilities: enum
>   Items: 'MIC_IN' 'LINE_IN'
>   Item0: 'MIC_IN'
> Simple mixer control 'Capture ZC',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [on]
>

In attachment there is a screenshot of alsamixer

All audio stuff are not hear at all.... :-(

After the output of the sgtl5000 I have a audio-booster and it is set at 
the maximum level.
I have another board based on the iMX28, SGTL5000 and the same audio 
booster and everything is working good. So I can suppose something 
related the initialization of the codec.

Any help?

Best Regards,
Gianluca Renzi
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

[-- Attachment #2: sgtl5000-ek360.png --]
[-- Type: image/png, Size: 48066 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

[-- Attachment #1: Type: text/plain, Size: 3022 bytes --]




-------- Forwarded Message --------
Subject: Issue on Linux 4.12-rc7 on iMX6 based board
Date: Wed, 28 Jun 2017 17:32:34 +0200
From: gianluca <gianlucarenzi@eurekelettronica.it>
To: alsa-devel@alsa-project.org <alsa-devel@alsa-project.org>

Hello list,

I have some issue using the sgtl5000 on two custom boards based with 
iMX6. One board has iMX6DL and the other has iMX6QP.

The issue is I have a (dramatically high) strange value on mixer 
settings (looks like a int32 limit or similar)

This is the output of amixer:
> # amixer
> Simple mixer control 'Headphone',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 127
>   Mono:
>   Front Left: Playback 0 [2147483647%] [-51.50dB] [on]
>   Front Right: Playback 0 [2147483647%] [-51.50dB] [on]
> Simple mixer control 'Headphone Mux',0
>   Capabilities: enum
>   Items: 'DAC' 'LINE_IN'
>   Item0: 'DAC'
> Simple mixer control 'Headphone Playback ZC',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [on]
> Simple mixer control 'PCM',0
>   Capabilities: pvolume
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 192
>   Mono:
>   Front Left: Playback 1 [2147483647%]
>   Front Right: Playback 0 [2147483647%]
> Simple mixer control 'Lineout',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 31
>   Mono:
>   Front Left: Playback 18 [2147483647%] [-6.50dB] [on]
>   Front Right: Playback 18 [2147483647%] [-6.50dB] [on]
> Simple mixer control 'Mic',0
>   Capabilities: volume volume-joined
>   Playback channels: Mono
>   Capture channels: Mono
>   Limits: 0 - 3
>   Mono: 0 [2147483647%] [0.00dB]
> Simple mixer control 'Capture',0
>   Capabilities: cvolume
>   Capture channels: Front Left - Front Right
>   Limits: Capture 0 - 15
>   Front Left: Capture 0 [2147483647%]
>   Front Right: Capture 0 [2147483647%]
> Simple mixer control 'Capture Attenuate Switch (-6dB)',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [off]
> Simple mixer control 'Capture Mux',0
>   Capabilities: enum
>   Items: 'MIC_IN' 'LINE_IN'
>   Item0: 'MIC_IN'
> Simple mixer control 'Capture ZC',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [on]
>

In attachment there is a screenshot of alsamixer

All audio stuff are not hear at all.... :-(

After the output of the sgtl5000 I have a audio-booster and it is set at 
the maximum level.
I have another board based on the iMX28, SGTL5000 and the same audio 
booster and everything is working good. So I can suppose something 
related the initialization of the codec.

Any help?

Best Regards,
Gianluca Renzi
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212


[-- Attachment #2: sgtl5000-ek360.png8 --]
[-- Type: image/png, Size: 12953 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[Fabio Estevam]

Hi Gianluca,

On Wed, Jun 28, 2017 at 12:34 PM, gianluca
<gianlucarenzi@eurekelettronica.it> wrote:

> Hello list,
>
> I have some issue using the sgtl5000 on two custom boards based with iMX6.
> One board has iMX6DL and the other has iMX6QP.
>
> The issue is I have a (dramatically high) strange value on mixer settings
> (looks like a int32 limit or similar)
>
> This is the output of amixer:
>>
>> # amixer
>> Simple mixer control 'Headphone',0
>>   Capabilities: pvolume pswitch pswitch-joined
>>   Playback channels: Front Left - Front Right
>>   Limits: Playback 0 - 127
>>   Mono:
>>   Front Left: Playback 0 [2147483647%] [-51.50dB] [on]
>>   Front Right: Playback 0 [2147483647%] [-51.50dB] [on]

Double check the codec hardware: is I2C communication working, are you
able to dump the SGTL5000 registers, check the codec power supplies,
MCLK, etc.

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

On 06/29/2017 01:37 PM, Fabio Estevam wrote:
> Hi Gianluca,
>
> On Wed, Jun 28, 2017 at 12:34 PM, gianluca
> <gianlucarenzi@eurekelettronica.it> wrote:
>
>> Hello list,
>>
>> I have some issue using the sgtl5000 on two custom boards based with iMX6.
>> One board has iMX6DL and the other has iMX6QP.
>>
>> The issue is I have a (dramatically high) strange value on mixer settings
>> (looks like a int32 limit or similar)
>>
>> This is the output of amixer:
>>>
>>> # amixer
>>> Simple mixer control 'Headphone',0
>>>   Capabilities: pvolume pswitch pswitch-joined
>>>   Playback channels: Front Left - Front Right
>>>   Limits: Playback 0 - 127
>>>   Mono:
>>>   Front Left: Playback 0 [2147483647%] [-51.50dB] [on]
>>>   Front Right: Playback 0 [2147483647%] [-51.50dB] [on]
>
> Double check the codec hardware: is I2C communication working,are you
> able to dump the SGTL5000 registers,

The i2c communication is working:

> # i2cdetect -y -a -r 0
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 00 -- -- -- -- -- -- -- -- -- UU -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
> 50: UU UU -- -- 54 -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

sgtl-5000 is 0xa address like specified in the device-tree:

> &i2c1 {
> 	clock-frequency = <100000>;
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&pinctrl_i2c1>;
> 	status = "okay";
>
> 	sgtl5000: codec@0a {
> 		compatible = "fsl,sgtl5000";
> 		reg = <0x0a>;
> 		clocks = <&clks IMX6QDL_CLK_CKO>;
> 		VDDA-supply = <&reg_3p3v>;
> 		VDDIO-supply = <&reg_3p3v>;
> 		VDDD-supply = <&reg_1p2v>;
> 		status = "okay";
> 	};

I did not check the voltage supply yet, but during bootup the kernel is 
saying:

> [    0.620196] sgtl5000 0-000a: sgtl5000 revision 0x11

So I suppose (at least) the Codec is powered and the i2c lines are 
working correctly.

> [    0.650568] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW
> [    0.673984] imx-sgtl5000 sound: sgtl5000 <-> 2028000.ssi mapping ok
>

It looks like some basic initialization stuff and probing are working 
good...

> [    0.698683] ALSA device list:
> [    0.698689]   #0: imx6-ek360-sgtl5000

...and the device is added to ALSA device-list.

In the device-tree the sound node is so configured:

> 	sound {
> 		compatible = "fsl,imx-audio-sgtl5000";
> 		model = "imx6-ek360-sgtl5000";
> 		ssi-controller = <&ssi1>;
> 		audio-codec = <&sgtl5000>;
> 		audio-routing =
> 			"MIC_IN", "Mic Jack",
> 			"Mic Jack", "Mic Bias",
> 			"Headphone Jack", "HP_OUT";
> 		mux-int-port = <1>;
> 		mux-ext-port = <4>;
> 		micbias-resistor-k-ohms = <2>;
> 		micbias-voltage-m-volts = <3000>;
> 		status = "okay";
> 	};

I do not know about the mux-int-port or mux-ext-port. The only thing I 
know is the hardware guy told me he routed the ssi (CLK and DAT) to:

AUD3_TXC_R (i2s_sclk)
AUD3_TXD   (i2s_din)
AUD3_TXFS  (i2s_lrclk)
AUD3_RXD   (i2s_dout)
SYS_MCLK   (GPIO_0_CLKO sys_mclk)

So I configured the pinmux for audio in the following way:

> 		pinctrl_audmux: audmuxgrp {
> 			fsl,pins = <
> 				/* SGTL5000 sys_mclk */
> 				MX6QDL_PAD_GPIO_0__CCM_CLKO1		0x030b0
> 				MX6QDL_PAD_CSI0_DAT4__AUD3_TXC		0x130b0
> 				MX6QDL_PAD_CSI0_DAT5__AUD3_TXD		0x110b0
> 				MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS		0x130b0
> 				MX6QDL_PAD_CSI0_DAT7__AUD3_RXD		0x130b0
> 			>;
> 		};

Are the values correct for that?

I was looking at the device-tree for imx6qdl-nit6xlite.dtsi because they 
are using the same pinout as ours.

check the codec power supplies,
> MCLK, etc.

How can I check or dump the SGTL5000 registers?

Regards,
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[Fabio Estevam]

On Thu, Jun 29, 2017 at 10:39 AM, gianluca
<gianlucarenzi@eurekelettronica.it> wrote:

> In the device-tree the sound node is so configured:
>
>>         sound {
>>                 compatible = "fsl,imx-audio-sgtl5000";
>>                 model = "imx6-ek360-sgtl5000";
>>                 ssi-controller = <&ssi1>;
>>                 audio-codec = <&sgtl5000>;
>>                 audio-routing =
>>                         "MIC_IN", "Mic Jack",
>>                         "Mic Jack", "Mic Bias",
>>                         "Headphone Jack", "HP_OUT";
>>                 mux-int-port = <1>;
>>                 mux-ext-port = <4>;

This should be mux-ext-port = <3>;

> I do not know about the mux-int-port or mux-ext-port. The only thing I know
> is the hardware guy told me he routed the ssi (CLK and DAT) to:
>
> AUD3_TXC_R (i2s_sclk)
> AUD3_TXD   (i2s_din)
> AUD3_TXFS  (i2s_lrclk)
> AUD3_RXD   (i2s_dout)
> SYS_MCLK   (GPIO_0_CLKO sys_mclk)

since you are using AUD3 pins.

>
> So I configured the pinmux for audio in the following way:
>
>>                 pinctrl_audmux: audmuxgrp {
>>                         fsl,pins = <
>>                                 /* SGTL5000 sys_mclk */
>>                                 MX6QDL_PAD_GPIO_0__CCM_CLKO1
>> 0x030b0
>>                                 MX6QDL_PAD_CSI0_DAT4__AUD3_TXC
>> 0x130b0
>>                                 MX6QDL_PAD_CSI0_DAT5__AUD3_TXD
>> 0x110b0
>>                                 MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS
>> 0x130b0
>>                                 MX6QDL_PAD_CSI0_DAT7__AUD3_RXD
>> 0x130b0
>>                         >;
>>                 };
>
>
> Are the values correct for that?

They should be good.

> How can I check or dump the SGTL5000 registers?

cat /sys/kernel/debug/regmap/xxx

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

On 06/29/2017 03:49 PM, Fabio Estevam wrote:
> On Thu, Jun 29, 2017 at 10:39 AM, gianluca
> <gianlucarenzi@eurekelettronica.it> wrote:
>
>> In the device-tree the sound node is so configured:
>>
>>>         sound {
>>>                 compatible = "fsl,imx-audio-sgtl5000";
>>>                 model = "imx6-ek360-sgtl5000";
>>>                 ssi-controller = <&ssi1>;
>>>                 audio-codec = <&sgtl5000>;
>>>                 audio-routing =
>>>                         "MIC_IN", "Mic Jack",
>>>                         "Mic Jack", "Mic Bias",
>>>                         "Headphone Jack", "HP_OUT";
>>>                 mux-int-port = <1>;
>>>                 mux-ext-port = <4>;
>
> This should be mux-ext-port = <3>;
>

I've already modified now.

>> I do not know about the mux-int-port or mux-ext-port. The only thing I know
>> is the hardware guy told me he routed the ssi (CLK and DAT) to:
>>
>> AUD3_TXC_R (i2s_sclk)
>> AUD3_TXD   (i2s_din)
>> AUD3_TXFS  (i2s_lrclk)
>> AUD3_RXD   (i2s_dout)
>> SYS_MCLK   (GPIO_0_CLKO sys_mclk)
>
> since you are using AUD3 pins.
>

So, are they good?

My only concern is the value after the MSYS_CLK (GPIO_0_CCM_CLK01). It 
is 0x030b0. Is this correct for output clock signal?

>>
>> So I configured the pinmux for audio in the following way:
>>
>>>                 pinctrl_audmux: audmuxgrp {
>>>                         fsl,pins = <
>>>                                 /* SGTL5000 sys_mclk */
>>>                                 MX6QDL_PAD_GPIO_0__CCM_CLKO1
>>> 0x030b0

The remaining pins seems to be configured as a lot of boards in the 
current 4.12-rc7 kernel. So I can assume they are good.

>>>                                 MX6QDL_PAD_CSI0_DAT4__AUD3_TXC
>>> 0x130b0
>>>                                 MX6QDL_PAD_CSI0_DAT5__AUD3_TXD
>>> 0x110b0
>>>                                 MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS
>>> 0x130b0
>>>                                 MX6QDL_PAD_CSI0_DAT7__AUD3_RXD
>>> 0x130b0
>>>                         >;
>>>                 };
>>
>>
>
> They should be good.
>
>> How can I check or dump the SGTL5000 registers?
>
> cat /sys/kernel/debug/regmap/xxx
>

I am missing the regmap. Should I configure kernel with additional CONFIG_ ?

I started from the imxv6_imxv7_defconfig, then modified to have the 
correct drivers module as built-in or dynamic.

Maybe am I missing something else??? :-(

Regards,
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[Fabio Estevam]

On Thu, Jun 29, 2017 at 11:24 AM, gianluca
<gianlucarenzi@eurekelettronica.it> wrote:

> So, are they good?

If your hardware really uses these pins, then yes :-)


> My only concern is the value after the MSYS_CLK (GPIO_0_CCM_CLK01). It is
> 0x030b0. Is this correct for output clock signal?

Most of the boards use 0x130b0. You should really check with a scope
and see if the MCLK is getting to the codec.
I suppose it is as the driver can read its ID register correctly.

> I am missing the regmap. Should I configure kernel with additional CONFIG_ ?

mount -t debugfs none /sys/kernel/debug

>
> I started from the imxv6_imxv7_defconfig, then modified to have the correct
> drivers module as built-in or dynamic.

imx_v6_v7_defconfig should give you working audio.

You should check in this scope if your getting SSI clock/data when
playing audio.

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

On 06/29/2017 04:24 PM, gianluca wrote:
> On 06/29/2017 03:49 PM, Fabio Estevam wrote:
>> On Thu, Jun 29, 2017 at 10:39 AM, gianluca
>> <gianlucarenzi@eurekelettronica.it> wrote:
>>
>>> In the device-tree the sound node is so configured:
>>>
>>>>         sound {
>>>>                 compatible = "fsl,imx-audio-sgtl5000";
>>>>                 model = "imx6-ek360-sgtl5000";
>>>>                 ssi-controller = <&ssi1>;
>>>>                 audio-codec = <&sgtl5000>;
>>>>                 audio-routing =
>>>>                         "MIC_IN", "Mic Jack",
>>>>                         "Mic Jack", "Mic Bias",
>>>>                         "Headphone Jack", "HP_OUT";
>>>>                 mux-int-port = <1>;
>>>>                 mux-ext-port = <4>;
>>
>> This should be mux-ext-port = <3>;
>>
>
> I've already modified now.
>
>>> I do not know about the mux-int-port or mux-ext-port. The only thing
>>> I know
>>> is the hardware guy told me he routed the ssi (CLK and DAT) to:
>>>
>>> AUD3_TXC_R (i2s_sclk)
>>> AUD3_TXD   (i2s_din)
>>> AUD3_TXFS  (i2s_lrclk)
>>> AUD3_RXD   (i2s_dout)
>>> SYS_MCLK   (GPIO_0_CLKO sys_mclk)
>>
>> since you are using AUD3 pins.
>>
>
> So, are they good?
>
> My only concern is the value after the MSYS_CLK (GPIO_0_CCM_CLK01). It
> is 0x030b0. Is this correct for output clock signal?
>
>>>
>>> So I configured the pinmux for audio in the following way:
>>>
>>>>                 pinctrl_audmux: audmuxgrp {
>>>>                         fsl,pins = <
>>>>                                 /* SGTL5000 sys_mclk */
>>>>                                 MX6QDL_PAD_GPIO_0__CCM_CLKO1
>>>> 0x030b0
>
> The remaining pins seems to be configured as a lot of boards in the
> current 4.12-rc7 kernel. So I can assume they are good.
>
>>>>                                 MX6QDL_PAD_CSI0_DAT4__AUD3_TXC
>>>> 0x130b0
>>>>                                 MX6QDL_PAD_CSI0_DAT5__AUD3_TXD
>>>> 0x110b0
>>>>                                 MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS
>>>> 0x130b0
>>>>                                 MX6QDL_PAD_CSI0_DAT7__AUD3_RXD
>>>> 0x130b0
>>>>                         >;
>>>>                 };
>>>
>>>
>>
>> They should be good.
>>
>>> How can I check or dump the SGTL5000 registers?
>>
>> cat /sys/kernel/debug/regmap/xxx
>>
>
> I am missing the regmap. Should I configure kernel with additional
> CONFIG_ ?
>
> I started from the imxv6_imxv7_defconfig, then modified to have the
> correct drivers module as built-in or dynamic.
>
> Maybe am I missing something else??? :-(
>

The funny thing is I can clearly hear the 'POP' of the speaker after 
some seconds the end of the audio stream...

> # aplay /usr/share/sounds/alsa/Front_Right.wav




-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

On 06/29/2017 04:30 PM, Fabio Estevam wrote:
> On Thu, Jun 29, 2017 at 11:24 AM, gianluca
> <gianlucarenzi@eurekelettronica.it> wrote:
>
>> So, are they good?
>
> If your hardware really uses these pins, then yes :-)
>

Now looking at other boards where our hardware-guy took the inspiration 
(i.e. iMX6 Rex from Fedevel) the device-tree is the same as mine.

> MX6QDL_PAD_GPIO_0__CCM_CLKO1		0x030b0

0x130b0 or 0x030b0 the only difference is the PAD_CTL_HYS 
      (1 << 16)

Maybe more strong to noise, but basically they are the same.

But I found an issue when playing data from aplay without specifing the 
device or specifying one:

> # aplay /usr/share/sounds/alsa/Front_Center.wav
> Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

or

> # aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Right.wav
> Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
> aplay: set_params:1233: Sample format non available
> Available formats:
> - S24_LE

Maybe some ALSA misconfigured????

This distro is a bootstrapped jessie Debian 8, so some configuration 
could be missing or not-so-good-configured.

>
> # aplay -L
> null
>     Discard all samples (playback) or generate zero samples (capture)
> pulse
>     PulseAudio Sound Server
> default:CARD=imx6ek360sgtl50
>     imx6-ek360-sgtl5000,
>     Default Audio Device
> sysdefault:CARD=imx6ek360sgtl50
>     imx6-ek360-sgtl5000,
>     Default Audio Device
> dmix:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Direct sample mixing device
> dsnoop:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Direct sample snooping device
> hw:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Direct hardware device without any conversions
> plughw:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Hardware device with all software conversions

Anybody has never faced an issue like this?

Regards,
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

On 06/29/2017 04:30 PM, Fabio Estevam wrote:
>
> Most of the boards use 0x130b0. You should really check with a scope
> and see if the MCLK is getting to the codec.
> I suppose it is as the driver can read its ID register correctly.
>
>> I am missing the regmap. Should I configure kernel with additional CONFIG_ ?
>
> mount -t debugfs none /sys/kernel/debug

Here we go!

> root@edelin:/sys/kernel/debug/regmap/0-000a# cat registers
> 000: a011
> 002: 0060
> 004: 0008
> 006: 0080
> 00a: 0010
> 00e: 020c
> 010: fcfc
> 014: 015f
> 020: 0000
> 022: 4000
> 024: 0022
> 026: 0068
> 028: 01f1
> 02a: 0200
> 02c: 0322
> 02e: 0d0d
> 030: 7260
> 032: 5000
> 034: 0000
> 036: 0017
> 03a: 0000
> 03c: 0000
> 100: 0000
> 102: 0000
> 104: 0040
> 106: 051f
> 108: 0000
> 10a: 0040
> 10c: 0000
> 10e: 0000
> 110: 0000
> 116: 002f
> 118: 002f
> 11a: 002f
> 11c: 002f
> 11e: 002f
> 120: 8000
> 122: 0000
> 124: 0510
> 126: 1473
> 128: 0028
> 12a: 0050
> 12c: 0000
> 12e: 0000
> 130: 0000
> 132: 0000
> 134: 0000
> 136: 0000
> 138: 0000
> 13a: 0000

now access:

> root@edelin:/sys/kernel/debug/regmap/0-000a# cat access
> 000: y y y n
> 002: y y n n
> 004: y y n n
> 006: y y n n
> 008: n y n n
> 00a: y y n n
> 00c: n y n n
> 00e: y y y n
> 010: y y n n
> 012: n y n n
> 014: y y n n
> 016: n y n n
> 018: n y n n
> 01a: n y n n
> 01c: n y n n
> 01e: n y n n
> 020: y y n n
> 022: y y n n
> 024: y y n n
> 026: y y n n
> 028: y y n n
> 02a: y y n n
> 02c: y y n n
> 02e: y y n n
> 030: y y n n
> 032: y y n n
> 034: y y n n
> 036: y y y n
> 038: n y n n
> 03a: y y n n
> 03c: y y n n
> 03e: n y n n
> 040: n y n n
> 042: n y n n
> 044: n y n n
> 046: n y n n
> 048: n y n n
> 04a: n y n n
> 04c: n y n n
> 04e: n y n n
> 050: n y n n
> 052: n y n n
> 054: n y n n
> 056: n y n n
> 058: n y n n
> 05a: n y n n
> 05c: n y n n
> 05e: n y n n
> 060: n y n n
> 062: n y n n
> 064: n y n n
> 066: n y n n
> 068: n y n n
> 06a: n y n n
> 06c: n y n n
> 06e: n y n n
> 070: n y n n
> 072: n y n n
> 074: n y n n
> 076: n y n n
> 078: n y n n
> 07a: n y n n
> 07c: n y n n
> 07e: n y n n
> 080: n y n n
> 082: n y n n
> 084: n y n n
> 086: n y n n
> 088: n y n n
> 08a: n y n n
> 08c: n y n n
> 08e: n y n n
> 090: n y n n
> 092: n y n n
> 094: n y n n
> 096: n y n n
> 098: n y n n
> 09a: n y n n
> 09c: n y n n
> 09e: n y n n
> 0a0: n y n n
> 0a2: n y n n
> 0a4: n y n n
> 0a6: n y n n
> 0a8: n y n n
> 0aa: n y n n
> 0ac: n y n n
> 0ae: n y n n
> 0b0: n y n n
> 0b2: n y n n
> 0b4: n y n n
> 0b6: n y n n
> 0b8: n y n n
> 0ba: n y n n
> 0bc: n y n n
> 0be: n y n n
> 0c0: n y n n
> 0c2: n y n n
> 0c4: n y n n
> 0c6: n y n n
> 0c8: n y n n
> 0ca: n y n n
> 0cc: n y n n
> 0ce: n y n n
> 0d0: n y n n
> 0d2: n y n n
> 0d4: n y n n
> 0d6: n y n n
> 0d8: n y n n
> 0da: n y n n
> 0dc: n y n n
> 0de: n y n n
> 0e0: n y n n
> 0e2: n y n n
> 0e4: n y n n
> 0e6: n y n n
> 0e8: n y n n
> 0ea: n y n n
> 0ec: n y n n
> 0ee: n y n n
> 0f0: n y n n
> 0f2: n y n n
> 0f4: n y n n
> 0f6: n y n n
> 0f8: n y n n
> 0fa: n y n n
> 0fc: n y n n
> 0fe: n y n n
> 100: y y n n
> 102: y y n n
> 104: y y n n
> 106: y y n n
> 108: y y n n
> 10a: y y n n
> 10c: y y n n
> 10e: y y n n
> 110: y y n n
> 112: n y n n
> 114: n y n n
> 116: y y n n
> 118: y y n n
> 11a: y y n n
> 11c: y y n n
> 11e: y y n n
> 120: y y n n
> 122: y y n n
> 124: y y n n
> 126: y y n n
> 128: y y n n
> 12a: y y n n
> 12c: y y n n
> 12e: y y n n
> 130: y y n n
> 132: y y n n
> 134: y y n n
> 136: y y n n
> 138: y y n n
> 13a: y y n n


cache-bypass
> root@edelin:/sys/kernel/debug/regmap/0-000a# cat cache_bypass
> N

cache-dirty
> root@edelin:/sys/kernel/debug/regmap/0-000a# cat cache_dirty
> N

cache-only
> root@edelin:/sys/kernel/debug/regmap/0-000a# cat cache_only
> N

name
> root@edelin:/sys/kernel/debug/regmap/0-000a# cat name
> sgtl5000

range
> root@edelin:/sys/kernel/debug/regmap/0-000a# cat range
> 0-6
> a-a
> e-10
> 14-14
> 20-36
> 3a-3c
> 100-110
> 116-13a

rbtree
> root@edelin:/sys/kernel/debug/regmap/0-000a# cat rbtree
> 2-3c (30)
> 100-13a (30)
> 2 nodes, 60 registers, average 30 registers, used 192 bytes


and now the ssi node:

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# ll
> total 0
> -r-------- 1 root root 0 Jan  1 00:00 access
> -rw------- 1 root root 0 Jan  1 00:00 cache_bypass
> -r-------- 1 root root 0 Jan  1 00:00 cache_dirty
> -rw------- 1 root root 0 Jan  1 00:00 cache_only
> -r-------- 1 root root 0 Jan  1 00:00 name
> -r-------- 1 root root 0 Jan  1 00:00 range
> -r-------- 1 root root 0 Jan  1 00:00 registers

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat name
> fsl-ssi-dai

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat registers
> 00: 00000000
> 04: 00000000
> 10: 00001058
> 18: 00003003
> 1c: 0000020d
> 20: 0000020d
> 24: 00040100
> 28: 00040100
> 2c: 00880088
> 30: 00000000
> 34: 00000000
> 38: 00000000
> 48: 00000000
> 4c: 00000000
> 50: 00000000
> 54: 00000000
> 58: 00000000

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat cache_bypass
> N

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat cache_dirty
> N

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat cache_only
> N

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat range
> 0-4
> 10-10
> 18-38
> 48-58

> root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat access
> 00: y y y n
> 04: y y y n
> 08: y n y y
> 0c: y n y y
> 10: y y n n
> 14: y y y y
> 18: y y n n
> 1c: y y n n
> 20: y y n n
> 24: y y n n
> 28: y y n n
> 2c: y y y n
> 30: y y n n
> 34: y y y n
> 38: y y y n
> 3c: y y y y
> 40: y y y y
> 44: y y y y
> 48: y y n n
> 4c: y y n n
> 50: y n y n
> 54: n y n n
> 58: n y n n

Now the pinmux

> device 21d8000.audmux
> state default
> type MUX_GROUP (2)
> controlling device 20e0000.iomuxc
> group audmuxgrp
> function imx6qp-ek360
>
> device 21d8000.audmux
> state default
> type CONFIGS_PIN (3)
> controlling device 20e0000.iomuxc
> pin MX6Q_PAD_CSI0_DAT7
> config 000130b0
>
> device 21d8000.audmux
> state default
> type CONFIGS_PIN (3)
> controlling device 20e0000.iomuxc
> pin MX6Q_PAD_CSI0_DAT4
> config 000130b0
>
> device 21d8000.audmux
> state default
> type CONFIGS_PIN (3)
> controlling device 20e0000.iomuxc
> pin MX6Q_PAD_CSI0_DAT5
> config 000110b0
>
> device 21d8000.audmux
> state default
> type CONFIGS_PIN (3)
> controlling device 20e0000.iomuxc
> pin MX6Q_PAD_CSI0_DAT6
> config 000130b0

>
> Pinctrl maps:
> device 20e0000.iomuxc
> state default
> type MUX_GROUP (2)
> controlling device 20e0000.iomuxc
> group hoggrp
> function imx6qp-ek360
>
> device 20e0000.iomuxc
> state default
> type CONFIGS_PIN (3)
> controlling device 20e0000.iomuxc
> pin MX6Q_PAD_GPIO_0
> config 000030b0

Now the Audio System On Chip (ASOC)
>
> root@edelin:/sys/kernel/debug/asoc# ls
> codecs  dais  imx6-ek360-sgtl5000  platforms
> root@edelin:/sys/kernel/debug/asoc# cat codecs
> sgtl5000.0-000a
> snd-soc-dummy
> root@edelin:/sys/kernel/debug/asoc# cat dais
> 2034000.asrc
> 2028000.ssi
> sgtl5000
> snd-soc-dummy-dai
> root@edelin:/sys/kernel/debug/asoc# cat platforms
> 2034000.asrc
> 2028000.ssi
> snd-soc-dummy

Any other value? :-/

> You should check in this scope if your getting SSI clock/data when
> playing audio.
>

The biggest problem is to solder into the pins of the sgtl5000. I have a 
signal analyzer (Saleae) but it need some wires to get the job done.

I would like to solve the problem by software first. I cannot believe a 
hardware problem...

Regards,
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board

[gianluca]

Now I did some great steps ahead! ;-)

I can assume there is some misconfigured alsa stuff in my debootstrapped 
armhf jessie distro!!!

First step: from Barebox bootloader I tried to move on/off all pins 
connected to the SGTL5000 from SoC iMX6. They are moving good, so I can 
assume _NO_HARDWARE_ issue.

Second step: burn a ubuntu armhf image (boundary-devices-jessie) to 
match up my system-boot (/etc/fstab and /etc/inittab), adding the 
/lib/modules/4.12-rc7/ directory and drivers, and add the uImage for 
4.12-rc7 on the sdcard.

Third step: burn on the sdcard the Barebox bootloader instead of the 
(unrunningble) u-boot for another board (Nitrogen).

Fourth step: turn on my board with this sdcard.

Sound is working. The levels of the capabilities (PCM, MIC, DAC, ...) 
are settable and they are working fine.

I can play and I can record. The only thing is the driver can use only 
S24_LE as frequeny for recording but afterall everything is working as 
expected.

Now the biggest question:

WTF are working alsa or its configuration in a deboostrapped armhf 
distribution? Actually this distro was upgraded two times:

1- Wheezy armel
2- Wheezy armel + armhf
3- Wheezy armhf
4- Jessie armhf
5- apt get dist-upgrade...

Something in between was wrong with alsa. Any help or configuration file 
to fix this issue???

> # aplay -L
> null
>     Discard all samples (playback) or generate zero samples (capture)
> default:CARD=imx6ek360sgtl50
>     imx6-ek360-sgtl5000,
>     Default Audio Device
> sysdefault:CARD=imx6ek360sgtl50
>     imx6-ek360-sgtl5000,
>     Default Audio Device
> dmix:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Direct sample mixing device
> dsnoop:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Direct sample snooping device
> hw:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Direct hardware device without any conversions
> plughw:CARD=imx6ek360sgtl50,DEV=0
>     imx6-ek360-sgtl5000,
>     Hardware device with all software conversions

>
>
> # aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi sgtl5000-0 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> root@nitrogen:~# arecord -l
> **** List of CAPTURE Hardware Devices ****
> card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi sgtl5000-0 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0


May I have a simple configuration file for this?


On 06/29/2017 06:28 PM, gianluca wrote:
> On 06/29/2017 04:30 PM, Fabio Estevam wrote:
>> On Thu, Jun 29, 2017 at 11:24 AM, gianluca
>> <gianlucarenzi@eurekelettronica.it> wrote:
>>
>>> So, are they good?
>>
>> If your hardware really uses these pins, then yes :-)
>>
>
> Now looking at other boards where our hardware-guy took the inspiration
> (i.e. iMX6 Rex from Fedevel) the device-tree is the same as mine.
>
>> MX6QDL_PAD_GPIO_0__CCM_CLKO1        0x030b0
>
> 0x130b0 or 0x030b0 the only difference is the PAD_CTL_HYS      (1 << 16)
>
> Maybe more strong to noise, but basically they are the same.
>
> But I found an issue when playing data from aplay without specifing the
> device or specifying one:
>
>> # aplay /usr/share/sounds/alsa/Front_Center.wav
>> Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate
>> 48000 Hz, Mono
>
> or
>
>> # aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Right.wav
>> Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate
>> 48000 Hz, Mono
>> aplay: set_params:1233: Sample format non available
>> Available formats:
>> - S24_LE
>
> Maybe some ALSA misconfigured????
>
> This distro is a bootstrapped jessie Debian 8, so some configuration
> could be missing or not-so-good-configured.
>

Regards,
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board [SOLVED]

[gianluca]

What did I do to fix this issue:

1- apt purge alsa-utils
2- apt install alsa-utils

Now everything is working as expected. Maybe some misconfigured stuff to 
have a (strangely enough) high value for property mixer and other stuff...

> # amixer
> Simple mixer control 'Headphone',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 127
>   Mono:
>   Front Left: Playback 63 [50%] [-20.00dB] [on]
>   Front Right: Playback 63 [50%] [-20.00dB] [on]
> Simple mixer control 'Headphone Mux',0
>   Capabilities: enum
>   Items: 'DAC' 'LINE_IN'
>   Item0: 'DAC'
> Simple mixer control 'Headphone Playback ZC',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [on]
> Simple mixer control 'PCM',0
>   Capabilities: pvolume
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 192
>   Mono:
>   Front Left: Playback 154 [80%]
>   Front Right: Playback 154 [80%]
> Simple mixer control 'Lineout',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 31
>   Mono:
>   Front Left: Playback 18 [58%] [-6.50dB] [on]
>   Front Right: Playback 18 [58%] [-6.50dB] [on]
> Simple mixer control 'Mic',0
>   Capabilities: volume volume-joined
>   Playback channels: Mono
>   Capture channels: Mono
>   Limits: 0 - 3
>   Mono: 0 [0%] [0.00dB]
> Simple mixer control 'Capture',0
>   Capabilities: cvolume
>   Capture channels: Front Left - Front Right
>   Limits: Capture 0 - 15
>   Front Left: Capture 12 [80%]
>   Front Right: Capture 12 [80%]
> Simple mixer control 'Capture Attenuate Switch (-6dB)',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [off]
> Simple mixer control 'Capture Mux',0
>   Capabilities: enum
>   Items: 'MIC_IN' 'LINE_IN'
>   Item0: 'MIC_IN'
> Simple mixer control 'Capture ZC',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [on]
> root@edelin:~#

...and everything is working good!


On 07/03/2017 11:36 AM, gianluca wrote:
> Now I did some great steps ahead! ;-)
>
> I can assume there is some misconfigured alsa stuff in my debootstrapped
> armhf jessie distro!!!
>
> First step: from Barebox bootloader I tried to move on/off all pins
> connected to the SGTL5000 from SoC iMX6. They are moving good, so I can
> assume _NO_HARDWARE_ issue.
>
> Second step: burn a ubuntu armhf image (boundary-devices-jessie) to
> match up my system-boot (/etc/fstab and /etc/inittab), adding the
> /lib/modules/4.12-rc7/ directory and drivers, and add the uImage for
> 4.12-rc7 on the sdcard.
>
> Third step: burn on the sdcard the Barebox bootloader instead of the
> (unrunningble) u-boot for another board (Nitrogen).
>
> Fourth step: turn on my board with this sdcard.
>
> Sound is working. The levels of the capabilities (PCM, MIC, DAC, ...)
> are settable and they are working fine.
>
> I can play and I can record. The only thing is the driver can use only
> S24_LE as frequeny for recording but afterall everything is working as
> expected.
>
> Now the biggest question:
>
> WTF are working alsa or its configuration in a deboostrapped armhf
> distribution? Actually this distro was upgraded two times:
>
> 1- Wheezy armel
> 2- Wheezy armel + armhf
> 3- Wheezy armhf
> 4- Jessie armhf
> 5- apt get dist-upgrade...
>
> Something in between was wrong with alsa. Any help or configuration file
> to fix this issue???
>
>> # aplay -L
>> null
>>     Discard all samples (playback) or generate zero samples (capture)
>> default:CARD=imx6ek360sgtl50
>>     imx6-ek360-sgtl5000,
>>     Default Audio Device
>> sysdefault:CARD=imx6ek360sgtl50
>>     imx6-ek360-sgtl5000,
>>     Default Audio Device
>> dmix:CARD=imx6ek360sgtl50,DEV=0
>>     imx6-ek360-sgtl5000,
>>     Direct sample mixing device
>> dsnoop:CARD=imx6ek360sgtl50,DEV=0
>>     imx6-ek360-sgtl5000,
>>     Direct sample snooping device
>> hw:CARD=imx6ek360sgtl50,DEV=0
>>     imx6-ek360-sgtl5000,
>>     Direct hardware device without any conversions
>> plughw:CARD=imx6ek360sgtl50,DEV=0
>>     imx6-ek360-sgtl5000,
>>     Hardware device with all software conversions
>
>>
>>
>> # aplay -l
>> **** List of PLAYBACK Hardware Devices ****
>> card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi
>> sgtl5000-0 []
>>   Subdevices: 1/1
>>   Subdevice #0: subdevice #0
>> root@nitrogen:~# arecord -l
>> **** List of CAPTURE Hardware Devices ****
>> card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi
>> sgtl5000-0 []
>>   Subdevices: 1/1
>>   Subdevice #0: subdevice #0
>
>
> May I have a simple configuration file for this?
>
>
> On 06/29/2017 06:28 PM, gianluca wrote:
>> On 06/29/2017 04:30 PM, Fabio Estevam wrote:
>>> On Thu, Jun 29, 2017 at 11:24 AM, gianluca
>>> <gianlucarenzi@eurekelettronica.it> wrote:
>>>
>>>> So, are they good?
>>>
>>> If your hardware really uses these pins, then yes :-)
>>>
>>
>> Now looking at other boards where our hardware-guy took the inspiration
>> (i.e. iMX6 Rex from Fedevel) the device-tree is the same as mine.
>>
>>> MX6QDL_PAD_GPIO_0__CCM_CLKO1        0x030b0
>>
>> 0x130b0 or 0x030b0 the only difference is the PAD_CTL_HYS      (1 << 16)
>>
>> Maybe more strong to noise, but basically they are the same.
>>
>> But I found an issue when playing data from aplay without specifing the
>> device or specifying one:
>>
>>> # aplay /usr/share/sounds/alsa/Front_Center.wav
>>> Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate
>>> 48000 Hz, Mono
>>
>> or
>>
>>> # aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Right.wav
>>> Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate
>>> 48000 Hz, Mono
>>> aplay: set_params:1233: Sample format non available
>>> Available formats:
>>> - S24_LE
>>
>> Maybe some ALSA misconfigured????
>>
>> This distro is a bootstrapped jessie Debian 8, so some configuration
>> could be missing or not-so-good-configured.
>>
>
> Regards,


-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212