Re: [alsa-devel] Alsa-devel Digest, Vol 149, Issue 28

18 Sep 2019

Hello Jaroslav-san,
This mail is regarding :
   3. Re: GIT: Regarding the issue we are facing in the commit
      37728639ae05de702825d96bd1d42e24ae772248 (Jaroslav Kysela)
Dne 03. 07. 19 v 14:17 Channaiah Vanitha (RBEI/ECF3) napsal(a):
...
Hello Jaroslav-san,
...
I think that it would be probably best to force the parameters for your hardware (--period-size and --buffer-size arguments for aplay or the time counterparts - --period-time and --buffer-time). The refining rules might not select the perfect configuration in some cases.
I tried to force parameters "period-size" in multiples of 2ms as our hardware supports 2ms period time data and buffer-size=twice period size.
But still I face the issue.
There is no exact 2ms period size for the rate 11025Hz, because it's float number 21.9780 (period size)... You may try values like 15,35,45,105 (anything which can match 11025 / PERIOD_SIZE without the remainder).
Jaroslav
We tried executing the playback use-case with below parameters as suggested.
But still we able to see: Unable to install hw params.
Kindly provide your feedback.
The output from below Hardware : 
a. RCAR salvator-xs which supports 2 channel.
b. IMX which supports 8 channel.
root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=15 /dev/random  
Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6
aplay: set_params:1411: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 96
CHANNELS: 6
RATE: NONE
PERIOD_TIME: 2000
PERIOD_SIZE: NONE
PERIOD_BYTES: (264 276)
PERIODS: (15 16)
BUFFER_TIME: (31927 31928)
BUFFER_SIZE: 352
BUFFER_BYTES: 4224
TICK_TIME: 0
root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=105 /dev/random  
Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6
aplay: set_params:1411: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 96
CHANNELS: 6
RATE: NONE
PERIOD_TIME: 10000
PERIOD_SIZE: NONE
PERIOD_BYTES: (1320 1332)
PERIODS: (2 3)
BUFFER_TIME: (29931 29932)
BUFFER_SIZE: 330
BUFFER_BYTES: 3960
TICK_TIME: 0
root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=35 /dev/random  
Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6
aplay: set_params:1411: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 96
CHANNELS: 6
RATE: NONE
PERIOD_TIME: 4000
PERIOD_SIZE: NONE
PERIOD_BYTES: (528 540)
PERIODS: (7 8)
BUFFER_TIME: (31927 31928)
BUFFER_SIZE: 352
BUFFER_BYTES: 4224
TICK_TIME: 0
root@rcar-gen3:~# aplay -v -Dentertainment_main -r11025 -c6 -fS16_LE --period-size=45 /dev/random  
Playing raw data '/dev/random' : Signed 16 bit Little Endian, Rate 11025 Hz, Channels 6
aplay: set_params:1411: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 96
CHANNELS: 6
RATE: NONE
PERIOD_TIME: 4000
PERIOD_SIZE: NONE
PERIOD_BYTES: (528 540)
PERIODS: (7 8)
BUFFER_TIME: (31927 31928)
BUFFER_SIZE: 352
BUFFER_BYTES: 4224
TICK_TIME: 0
Best regards,
Vanitha Channaiah
RBEI/ECF3
Tel. +91 80 6136-4436
-----Original Message-----
From: Alsa-devel alsa-devel-bounces@alsa-project.org On Behalf Of alsa-devel-request@alsa-project.org
Sent: Thursday, July 4, 2019 5:32 PM
To: alsa-devel@alsa-project.org
Subject: Alsa-devel Digest, Vol 149, Issue 28
Send Alsa-devel mailing list submissions to
    alsa-devel@alsa-project.org
To subscribe or unsubscribe via the World Wide Web, visit
    https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
or, via email, send a message with subject or body 'help' to
    alsa-devel-request@alsa-project.org
You can reach the person managing the list at
    alsa-devel-owner@alsa-project.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Alsa-devel digest..."
Today's Topics:
1. Re: [PATCH v2 1/2] ASoC: SOF: add flag for position update
      ipc (Kai Vehmanen)
   2. Re: [PATCH v2 2/2] ASoC: SOF: Intel: fix reset of
      host_period_bytes (Kai Vehmanen)
   3. Re: GIT: Regarding the issue we are facing in the commit
      37728639ae05de702825d96bd1d42e24ae772248 (Jaroslav Kysela)
   4. Re: [PATCH v2 1/2] ASoC: SOF: add flag for position update
      ipc (Keyon Jie)
   5. bug in playing 6-channel sound (Julian Bradfield)
   6. Re: [PATCH v2 1/2] ASoC: SOF: add flag for position update
      ipc (Kai Vehmanen)
   7. Re: [PATCH v2 34/35] sound/soc/codecs: Use kmemdup rather
      than duplicating its implementation (Richard Fitzgerald)
   8. audio lost from speaker after reboot from windows on the
      device ALC295 (He, Bo)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Jul 2019 13:03:06 +0300 (EEST)
From: Kai Vehmanen kai.vehmanen@linux.intel.com
To: Keyon Jie yang.jie@linux.intel.com
Cc: alsa-devel@alsa-project.org, ranjani.sridharan@linux.intel.com,
    Marcin Rajwa marcin.rajwa@linux.intel.com,
    pierre-louis.bossart@linux.intel.com
Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: SOF: add flag for
    position update ipc
Message-ID: alpine.DEB.2.21.1907041254100.4409@eliteleevi
Content-Type: text/plain; charset=US-ASCII
Hi,
patch looks good, but commit message could be improved.
On Wed, 3 Jul 2019, Keyon Jie wrote:
...
In some cases, FW might need use the host_period_bytes even no 
position update ipc reqiured from driver, here add another flag for 
position update, and preserve host_period_bytes for FW to use.
Speculation on what FW might do is not really needed. The host_period_bytes field has been overloaded with multiple semantics and this patch clears that, right. How about:
""
Remove the special case semantics of 'host_period_bytes==0'.
Add a new field 'no_period_irq' to signal whether period elapsed IPC should be sent and use 'host_period_bytes' only for period size.
""
...
This might require corresponding FW change and ABI alignment.
This is not helpful -- we know this _is_ a minor ABI change and needs to be aligned with FW.
Br, Kai
------------------------------
Message: 2
Date: Thu, 4 Jul 2019 13:05:21 +0300 (EEST)
From: Kai Vehmanen kai.vehmanen@linux.intel.com
To: Keyon Jie yang.jie@linux.intel.com
Cc: alsa-devel@alsa-project.org, ranjani.sridharan@linux.intel.com,
    Marcin Rajwa marcin.rajwa@linux.intel.com,
    pierre-louis.bossart@linux.intel.com
Subject: Re: [alsa-devel] [PATCH v2 2/2] ASoC: SOF: Intel: fix reset
    of host_period_bytes
Message-ID: alpine.DEB.2.21.1907041304101.4409@eliteleevi
Content-Type: text/plain; charset=US-ASCII
Hi,
On Wed, 3 Jul 2019, Keyon Jie wrote:
...
From: Marcin Rajwa marcin.rajwa@linux.intel.com
This patch prevents the reset of host period bytes.
The parameter has been used to keep information about completion of 
period copy. Right now we keep this information in period_irq.
Signed-off-by: Marcin Rajwa marcin.rajwa@linux.intel.com
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
looks good, for this patch:
Reviewed-by: Kai Vehmanen kai.vehmanen@linux.intel.com
------------------------------
Message: 3
Date: Thu, 4 Jul 2019 12:18:24 +0200
From: Jaroslav Kysela perex@perex.cz
To: "Channaiah Vanitha (RBEI/ECF3)" Vanitha.Channaiah@in.bosch.com
Cc: "Wischer Timo (ADITG/ESS)" twischer@de.adit-jv.com,
    "alsa-devel@alsa-project.org" alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] GIT: Regarding the issue we are facing in
    the commit 37728639ae05de702825d96bd1d42e24ae772248
Message-ID: 556614e1-acba-635c-beed-6484fb887299@perex.cz
Content-Type: text/plain; charset=utf-8
Dne 03. 07. 19 v 14:17 Channaiah Vanitha (RBEI/ECF3) napsal(a):
...
Hello Jaroslav-san,
...
I think that it would be probably best to force the parameters for your hardware (--period-size and --buffer-size arguments for aplay or the time counterparts - --period-time and --buffer-time). The refining rules might not select the perfect configuration in some cases.
I tried to force parameters "period-size" in multiples of 2ms as our hardware supports 2ms period time data and buffer-size=twice period size.
But still I face the issue.
There is no exact 2ms period size for the rate 11025Hz, because it's float number 21.9780 (period size)... You may try values like 15,35,45,105 (anything which can match 11025 / PERIOD_SIZE without the remainder).
Jaroslav
--
Jaroslav Kysela perex@perex.cz
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
------------------------------
Message: 4
Date: Thu, 4 Jul 2019 18:29:20 +0800
From: Keyon Jie yang.jie@linux.intel.com
To: Kai Vehmanen kai.vehmanen@linux.intel.com
Cc: alsa-devel@alsa-project.org, ranjani.sridharan@linux.intel.com,
    Marcin Rajwa marcin.rajwa@linux.intel.com,
    pierre-louis.bossart@linux.intel.com
Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: SOF: add flag for
    position update ipc
Message-ID: 3788800e-7050-d68a-bec6-5b443fd0d563@linux.intel.com
Content-Type: text/plain; charset=utf-8; format=flowed
On 2019/7/4 ??6:03, Kai Vehmanen wrote:
...
Hi,
patch looks good, but commit message could be improved.
On Wed, 3 Jul 2019, Keyon Jie wrote:
...
In some cases, FW might need use the host_period_bytes even no position
update ipc reqiured from driver, here add another flag for position update,
and preserve host_period_bytes for FW to use.
Speculation on what FW might do is not really needed. The
host_period_bytes field has been overloaded with multiple
semantics and this patch clears that, right. How about:
Well, to me it is flavor choice, Ranjani suggested to illustrate the use 
case where the FW will use this host_period_bytes, and I agreed this 
will help people to understand why we need this change.
...
""
Remove the special case semantics of 'host_period_bytes==0'.
Add a new field 'no_period_irq' to signal whether period elapsed
IPC should be sent and use 'host_period_bytes' only for
period size.
""
...
This might require corresponding FW change and ABI alignment.
This is not helpful -- we know this _is_ a minor ABI change
and needs to be aligned with FW.
It is minor change, but the FW change is still required, otherwise, we 
will get extra position update IPCs which may confuse the driver, please 
refer to here:
https://github.com/thesofproject/sof/pull/1592
Thanks,
~Keyon
...
Br, Kai

Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
------------------------------
Message: 5
Date: Thu, 4 Jul 2019 11:46:20 +0100
From: Julian Bradfield jalsa-devel@jcbradfield.org
To: alsa-devel@alsa-project.org
Subject: [alsa-devel] bug in playing 6-channel sound
Message-ID: 23837.55548.631053.741245@vis.stevens-bradfield.com
Content-Type: text/plain; charset=us-ascii
Some five years ago, the following post
https://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/072265.h...
reported a failure to play six-channel sound, that could be worked
around by setting the prealloc value for the device to various values
*other than* the default 64.
I have just run into this playing a movie from my laptop (Thinkpad
Yoga X1, Intel HDA PCH sound card outputting through HDMI) running
Xubuntu 18.04, up to date as at the time of posting.
I see exactly the same problem as in that post, and the same
workaround works for me - I tried prealloc values 63,65,32,128, and
any of them is ok.
I'm a bit baffled that such a problem has survived for several years.
If any developer would like me to provide debugging information,
please get in touch - I have some time available at present, but not
enough to learn ALSA and debug it myself!
I will remain subscribed to the list for a few weeks to read any
followups.
------------------------------
Message: 6
Date: Thu, 4 Jul 2019 14:00:31 +0300 (EEST)
From: Kai Vehmanen kai.vehmanen@linux.intel.com
To: Keyon Jie yang.jie@linux.intel.com
Cc: alsa-devel@alsa-project.org, Marcin Rajwa
    marcin.rajwa@linux.intel.com, ranjani.sridharan@linux.intel.com, Kai
    Vehmanen kai.vehmanen@linux.intel.com,
    pierre-louis.bossart@linux.intel.com
Subject: Re: [alsa-devel] [PATCH v2 1/2] ASoC: SOF: add flag for
    position update ipc
Message-ID: alpine.DEB.2.21.1907041344240.4409@eliteleevi
Content-Type: text/plain; charset=US-ASCII
Hi,
On Thu, 4 Jul 2019, Keyon Jie wrote:
...
Well, to me it is flavor choice, Ranjani suggested to illustrate the use 
case where the FW will use this host_period_bytes, and I agreed this 
will help people to understand why we need this change.
hmm, ok. So maybe add "Allows FW to use 'host_period_bytes' field
for its original purpose" to my proposed wording..?
...
...
This is not helpful -- we know this _is_ a minor ABI change
and needs to be aligned with FW.
It is minor change, but the FW change is still required, otherwise, we 
will get extra position update IPCs which may confuse the driver, please
[...]
...
https://github.com/thesofproject/sof/pull/1592
Ack, but we know this already so best to put the accurate 
description in the commit message. The "might require FW change"
is a bit scary statement in a patch touching ABI structs. ;)
------------------------------
Message: 7
Date: Thu, 4 Jul 2019 12:47:29 +0100
From: Richard Fitzgerald rf@opensource.cirrus.com
To: Fuqian Huang huangfq.daxian@gmail.com
Cc: alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
    Takashi Iwai tiwai@suse.com, Liam Girdwood lgirdwood@gmail.com,
    Mark Brown broonie@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH v2 34/35] sound/soc/codecs: Use
    kmemdup rather than duplicating its implementation
Message-ID:
    52ee7351-19fc-4fd3-33f8-9392a4ad9526@opensource.cirrus.com
Content-Type: text/plain; charset="utf-8"; format=flowed
Commit message title prefix should be "ASoC: wm0010:" not "sound/soc
/codecs:". Take a look at other patches to the same files.
...
kmemdup is introduced to duplicate a region of memory in a neat way.
Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
write the size twice (sometimes lead to mistakes), kmemdup improves
readability, leads to smaller code and also reduce the chances of mistakes.
Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy.
Acked-by: Richard Fitzgerald rf@opensource.cirrus.com
Signed-off-by: Fuqian Huang huangfq.daxian@gmail.com

Changes in v2:

Fix a typo in commit message (memset -> memcpy)
Split into two patches

sound/soc/codecs/wm0010.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c
index 727d6703c905..807826f30f58 100644
--- a/sound/soc/codecs/wm0010.c
+++ b/sound/soc/codecs/wm0010.c
@@ -515,7 +515,7 @@ static int wm0010_stage2_load(struct snd_soc_component *component)
   dev_dbg(component->dev, "Downloading %zu byte stage 2 loader\n", fw->size);
/* Copy to local buffer first as vmalloc causes problems for dma */

img = kzalloc(fw->size, GFP_KERNEL | GFP_DMA);


img = kmemdup(&fw->data[0], fw->size, GFP_KERNEL | GFP_DMA);
if (!img) {
ret = -ENOMEM;
goto abort2;

@@ -527,8 +527,6 @@ static int wm0010_stage2_load(struct snd_soc_component *component)
   	goto abort1;
   }

memcpy(img, &fw->data[0], fw->size);
spi_message_init(&m);
 memset(&t, 0, sizeof(t));
 t.rx_buf = out;

------------------------------
Message: 8
Date: Thu, 4 Jul 2019 12:02:17 +0000
From: "He, Bo" bo.he@intel.com
To: "kailang@realtek.com" kailang@realtek.com,
    "alsa-devel@alsa-project.org" alsa-devel@alsa-project.org,
    "linux-kernel@vger.kernel.org" linux-kernel@vger.kernel.org
Cc: "chiu@endlessm.com" chiu@endlessm.com, "tiwai@suse.com"
    tiwai@suse.com, "drake@endlessm.com" drake@endlessm.com,
    "hui.wang@canonical.com" hui.wang@canonical.com,
    "jian-hong@endlessm.com" jian-hong@endlessm.com
Subject: [alsa-devel] audio lost from speaker after reboot from
    windows on the device ALC295
Message-ID:
    CD6925E8781EFD4D8E11882D20FC406D52AB58B6@SHSMSX104.ccr.corp.intel.com
    
Content-Type: text/plain; charset="us-ascii"
Hi, patch_realtek.c maintainer:
    I see one issue that reboot from windows and boot to ubuntu, the audio lost from speaker, I suspect there are some bugs in patch_realtek.c drivers,  the device is ALC295 and the device id is 0x10ec0295.
I have done the below experiments:
1. reboot from windows to windows, the audio is persist .
2. reboot from windows to ubuntu, the audio lost from speaker, but can hear if I hotplug one earphone.
3. if the issue reproduce after reboot from windows, reboot the ubuntu can't restore the audio, I suspect it's warm reset.
4. if I write the port 0xcf9 with 0xe to do cold reset, the audio can restore.
5. if I do suspend/resume, the audio can restore, I suspect do cold boot and suspend will trigger the platform reset to reset the ALC295.
6. if I do double function reset (write the verb 0x7ff in alc_init), the audio is still can't restore.
snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* Function reset */
snd_hda_codec_write(codec, 0x01, 0, AC_VERB_SET_CODEC_RESET, 0); /* double Function reset */
7. the issue is first found on kernel 4.19.50, I still see the issue with the latest kernel 5.2-rc2, is it possible windows change some default registers, but ALC295 don't initialize the register?
------------------------------
Subject: Digest Footer
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
------------------------------
End of Alsa-devel Digest, Vol 149, Issue 28
*******************************************

    

Channaiah Vanitha (RBEI/ECF3)

tags (0)

participants (1)