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@xxxxxxxxxxxxxxxx> On Behalf Of alsa-devel-request@xxxxxxxxxxxxxxxx
Sent: Thursday, July 4, 2019 5:32 PM
To: alsa-devel@xxxxxxxxxxxxxxxx
Subject: Alsa-devel Digest, Vol 149, Issue 28
Send Alsa-devel mailing list submissions to
alsa-devel@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx
You can reach the person managing the list at
alsa-devel-owner@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx>
To: Keyon Jie <yang.jie@xxxxxxxxxxxxxxx>
Cc: alsa-devel@xxxxxxxxxxxxxxxx, ranjani.sridharan@xxxxxxxxxxxxxxx,
Marcin Rajwa <marcin.rajwa@xxxxxxxxxxxxxxx>,
pierre-louis.bossart@xxxxxxxxxxxxxxx
Subject: Re: [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@xxxxxxxxxxxxxxx>
To: Keyon Jie <yang.jie@xxxxxxxxxxxxxxx>
Cc: alsa-devel@xxxxxxxxxxxxxxxx, ranjani.sridharan@xxxxxxxxxxxxxxx,
Marcin Rajwa <marcin.rajwa@xxxxxxxxxxxxxxx>,
pierre-louis.bossart@xxxxxxxxxxxxxxx
Subject: Re: [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@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxx>
> Signed-off-by: Keyon Jie <yang.jie@xxxxxxxxxxxxxxx>
looks good, for this patch:
Reviewed-by: Kai Vehmanen <kai.vehmanen@xxxxxxxxxxxxxxx>
------------------------------
Message: 3
Date: Thu, 4 Jul 2019 12:18:24 +0200
From: Jaroslav Kysela <perex@xxxxxxxx>
To: "Channaiah Vanitha (RBEI/ECF3)" <Vanitha.Channaiah@xxxxxxxxxxxx>
Cc: "Wischer Timo \(ADITG/ESS\)" <twischer@xxxxxxxxxxxxxx>,
"alsa-devel@xxxxxxxxxxxxxxxx" <alsa-devel@xxxxxxxxxxxxxxxx>
Subject: Re: GIT: Regarding the issue we are facing in
the commit 37728639ae05de702825d96bd1d42e24ae772248
Message-ID: <556614e1-acba-635c-beed-6484fb887299@xxxxxxxx>
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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
------------------------------
Message: 4
Date: Thu, 4 Jul 2019 18:29:20 +0800
From: Keyon Jie <yang.jie@xxxxxxxxxxxxxxx>
To: Kai Vehmanen <kai.vehmanen@xxxxxxxxxxxxxxx>
Cc: alsa-devel@xxxxxxxxxxxxxxxx, ranjani.sridharan@xxxxxxxxxxxxxxx,
Marcin Rajwa <marcin.rajwa@xxxxxxxxxxxxxxx>,
pierre-louis.bossart@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v2 1/2] ASoC: SOF: add flag for
position update ipc
Message-ID: <3788800e-7050-d68a-bec6-5b443fd0d563@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx>
To: alsa-devel@xxxxxxxxxxxxxxxx
Subject: bug in playing 6-channel sound
Message-ID: <23837.55548.631053.741245@xxxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
To: Keyon Jie <yang.jie@xxxxxxxxxxxxxxx>
Cc: alsa-devel@xxxxxxxxxxxxxxxx, Marcin Rajwa
<marcin.rajwa@xxxxxxxxxxxxxxx>, ranjani.sridharan@xxxxxxxxxxxxxxx, Kai
Vehmanen <kai.vehmanen@xxxxxxxxxxxxxxx>,
pierre-louis.bossart@xxxxxxxxxxxxxxx
Subject: Re: [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@xxxxxxxxxxxxxxxxxxxxx>
To: Fuqian Huang <huangfq.daxian@xxxxxxxxx>
Cc: alsa-devel@xxxxxxxxxxxxxxxx, patches@xxxxxxxxxxxxxxxxxxxxx,
Takashi Iwai <tiwai@xxxxxxxx>, Liam Girdwood <lgirdwood@xxxxxxxxx>,
Mark Brown <broonie@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v2 34/35] sound/soc/codecs: Use
kmemdup rather than duplicating its implementation
Message-ID:
<52ee7351-19fc-4fd3-33f8-9392a4ad9526@xxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Fuqian Huang <huangfq.daxian@xxxxxxxxx>
> ---
> 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@xxxxxxxxx>
To: "kailang@xxxxxxxxxxx" <kailang@xxxxxxxxxxx>,
"alsa-devel@xxxxxxxxxxxxxxxx" <alsa-devel@xxxxxxxxxxxxxxxx>,
"linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>
Cc: "chiu@xxxxxxxxxxxx" <chiu@xxxxxxxxxxxx>, "tiwai@xxxxxxxx"
<tiwai@xxxxxxxx>, "drake@xxxxxxxxxxxx" <drake@xxxxxxxxxxxx>,
"hui.wang@xxxxxxxxxxxxx" <hui.wang@xxxxxxxxxxxxx>,
"jian-hong@xxxxxxxxxxxx" <jian-hong@xxxxxxxxxxxx>
Subject: audio lost from speaker after reboot from
windows on the device ALC295
Message-ID:
<CD6925E8781EFD4D8E11882D20FC406D52AB58B6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
------------------------------
End of Alsa-devel Digest, Vol 149, Issue 28
*******************************************
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
