[alsa-devel] Alsa-devel Digest, Vol 149, Issue 28
Channaiah Vanitha (RBEI/ECF3)
Vanitha.Channaiah at in.bosch.com
Wed Sep 18 06:59:09 CEST 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 at 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 at 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 at 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 at 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 at alsa-project.org> On Behalf Of alsa-devel-request at alsa-project.org
Sent: Thursday, July 4, 2019 5:32 PM
To: alsa-devel at alsa-project.org
Subject: Alsa-devel Digest, Vol 149, Issue 28
Send Alsa-devel mailing list submissions to
alsa-devel at 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 at alsa-project.org
You can reach the person managing the list at
alsa-devel-owner at 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 at linux.intel.com>
To: Keyon Jie <yang.jie at linux.intel.com>
Cc: alsa-devel at alsa-project.org, ranjani.sridharan at linux.intel.com,
Marcin Rajwa <marcin.rajwa at linux.intel.com>,
pierre-louis.bossart at 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 at 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 at linux.intel.com>
To: Keyon Jie <yang.jie at linux.intel.com>
Cc: alsa-devel at alsa-project.org, ranjani.sridharan at linux.intel.com,
Marcin Rajwa <marcin.rajwa at linux.intel.com>,
pierre-louis.bossart at 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 at eliteleevi>
Content-Type: text/plain; charset=US-ASCII
Hi,
On Wed, 3 Jul 2019, Keyon Jie wrote:
> From: Marcin Rajwa <marcin.rajwa at 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 at linux.intel.com>
> Signed-off-by: Keyon Jie <yang.jie at linux.intel.com>
looks good, for this patch:
Reviewed-by: Kai Vehmanen <kai.vehmanen at linux.intel.com>
------------------------------
Message: 3
Date: Thu, 4 Jul 2019 12:18:24 +0200
From: Jaroslav Kysela <perex at perex.cz>
To: "Channaiah Vanitha (RBEI/ECF3)" <Vanitha.Channaiah at in.bosch.com>
Cc: "Wischer Timo \(ADITG/ESS\)" <twischer at de.adit-jv.com>,
"alsa-devel at alsa-project.org" <alsa-devel at 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 at 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 at 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 at linux.intel.com>
To: Kai Vehmanen <kai.vehmanen at linux.intel.com>
Cc: alsa-devel at alsa-project.org, ranjani.sridharan at linux.intel.com,
Marcin Rajwa <marcin.rajwa at linux.intel.com>,
pierre-louis.bossart at 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 at 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 at 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 at jcbradfield.org>
To: alsa-devel at alsa-project.org
Subject: [alsa-devel] bug in playing 6-channel sound
Message-ID: <23837.55548.631053.741245 at 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.html
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 at linux.intel.com>
To: Keyon Jie <yang.jie at linux.intel.com>
Cc: alsa-devel at alsa-project.org, Marcin Rajwa
<marcin.rajwa at linux.intel.com>, ranjani.sridharan at linux.intel.com, Kai
Vehmanen <kai.vehmanen at linux.intel.com>,
pierre-louis.bossart at 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 at 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 at opensource.cirrus.com>
To: Fuqian Huang <huangfq.daxian at gmail.com>
Cc: alsa-devel at alsa-project.org, patches at opensource.cirrus.com,
Takashi Iwai <tiwai at suse.com>, Liam Girdwood <lgirdwood at gmail.com>,
Mark Brown <broonie at kernel.org>, linux-kernel at 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 at 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 at opensource.cirrus.com>
> Signed-off-by: Fuqian Huang <huangfq.daxian at 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 at intel.com>
To: "kailang at realtek.com" <kailang at realtek.com>,
"alsa-devel at alsa-project.org" <alsa-devel at alsa-project.org>,
"linux-kernel at vger.kernel.org" <linux-kernel at vger.kernel.org>
Cc: "chiu at endlessm.com" <chiu at endlessm.com>, "tiwai at suse.com"
<tiwai at suse.com>, "drake at endlessm.com" <drake at endlessm.com>,
"hui.wang at canonical.com" <hui.wang at canonical.com>,
"jian-hong at endlessm.com" <jian-hong at endlessm.com>
Subject: [alsa-devel] audio lost from speaker after reboot from
windows on the device ALC295
Message-ID:
<CD6925E8781EFD4D8E11882D20FC406D52AB58B6 at 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 at alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
------------------------------
End of Alsa-devel Digest, Vol 149, Issue 28
*******************************************
More information about the Alsa-devel
mailing list