September 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Licence change for your alsa-lib UCM commits (Marcin Juszkiewicz: 5 total)
by Jaroslav Kysela 18 Sep '19

18 Sep '19

As discussed, we would like to move the UCM configuration files from the alsa-lib repository to new alsa-ucm-conf repository with the licence change from LGPL-2.1 to BSD-3-Clause. I would like to check, if you agree with this licence change. Please, answer to this e-mail and write your agreement / disagreement (keep CC to the alsa-devel mailing list for the archiving purposes). Thank you for your time and co-operation. Reference: https://mailman.alsa-project.org/pipermail/alsa-devel/2019-July/153257.html List of your commit(s): f07c14b08280fb461b7f070d55a625e1f5e88a1e conf/ucm: DAISY-I2S: add Samsung ARM Chromebook UCM config from ChromeOS 5b019ea310e6a5d6ff8933bcbca1f3f3471be33b conf/ucm: PandaBoard: add UCM config from Ubuntu 9d0f93af0b35bfdcbd3d758d98715508b69d6008 conf/ucm: PandaBoardES: add UCM config from Ubuntu 7db247be11381bef6e38a41f1d51fa78a99350b5 conf/ucm: SDP4430: add UCM config from Ubuntu 52de910868f56ee7e6b07a1a2ad6a54913f745d0 conf/ucm: tegraalc5632: add UCM config from Ubuntu --- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

15 19

[alsa-devel] 5.1 to stereo using libasound
by Eric Desjardins 18 Sep '19

18 Sep '19

Hi, I am playing a mkv with 5.1 channels from a mkv. I configure libasound for 6 channels and I feed them interleave audio using snd_pcm_writei. I use the default pulse audio device. So far, nothing is wrong. However, I do not ear things correctly. I listen this on my stereo speaker. There is no mixdown to stereo and I was wondering how to do that. I tried to use chmap api but anything I try on the default device returns an error. I was wondering what was the correct way to do that? Using the mixing api? How do we detect that my device output stereo if chmap doesn't work? I am on a ubuntu 18.04 linux box. Thanks, Eric

2 3

[alsa-devel] [PATCH v6 0/4] Add HDMI jack support on RK3288
by Cheng-Yi Chiang 18 Sep '19

18 Sep '19

This patch series supports HDMI jack reporting on RK3288, which uses DRM dw-hdmi driver and hdmi-codec codec driver. The previous discussion about reporting jack status using hdmi-notifier and drm_audio_component is at https://lore.kernel.org/patchwork/patch/1083027/ The new approach is to use a callback mechanism that is specific to hdmi-codec. The dependent change on hdmi-codec.c https://patchwork.kernel.org/patch/11047447 has been picked up by Mark Brown in ASoC tree for-5.4 branch. Changes from v5 to v6: 1. Remove the patch for sound/soc/codecs/hdmi-codec.c because it is accepted. 2. Rebase the rest of patches based on drm-misc-next tree. Cheng-Yi Chiang (4): drm: bridge: dw-hdmi: Report connector status using callback drm: dw-hdmi-i2s: Use fixed id for codec device ASoC: rockchip_max98090: Add dai_link for HDMI ASoC: rockchip_max98090: Add HDMI jack support .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 13 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 41 ++++++- include/drm/bridge/dw_hdmi.h | 4 + sound/soc/rockchip/Kconfig | 3 +- sound/soc/rockchip/rk3288_hdmi_analog.c | 3 +- sound/soc/rockchip/rockchip_max98090.c | 116 ++++++++++++++---- 6 files changed, 153 insertions(+), 27 deletions(-) -- 2.23.0.237.gc6a4ce50a0-goog

2 6

[alsa-devel] [PATCH v2] ASoC: atmel_ssc_dai: Remove wrong spinlock usage
by Gregory CLEMENT 18 Sep '19

18 Sep '19

A potential bug was reported in the email "[BUG] atmel_ssc_dai: a possible sleep-in-atomic bug in atmel_ssc_shutdown"[1] Indeed in the function atmel_ssc_shutdown() free_irq() was called in a critical section protected by spinlock. However this spinlock is only used in atmel_ssc_shutdown() and atmel_ssc_startup() functions. After further analysis, it occurred that the call to these function are already protected by mutex used on the calling functions. Then we can remove the spinlock which will fix this bug as a side effect. Thanks to this patch the following message disappears: "BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909" [1]: https://www.spinics.net/lists/alsa-devel/msg71286.html Reviewed-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> --- Changelog: v1 -> v2: - Removed the spinlock from the atmel_ssc_info struct - Added the Reviewed-by flag form Alex sound/soc/atmel/atmel_ssc_dai.c | 12 ++---------- sound/soc/atmel/atmel_ssc_dai.h | 1 - 2 files changed, 2 insertions(+), 11 deletions(-) diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index 6f89483ac88c..786b48ae4905 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -116,19 +116,16 @@ static struct atmel_pcm_dma_params ssc_dma_params[NUM_SSC_DEVICES][2] = { static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = { { .name = "ssc0", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[0].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, { .name = "ssc1", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[1].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, { .name = "ssc2", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[2].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, @@ -317,13 +314,10 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, snd_soc_dai_set_dma_data(dai, substream, dma_params); - spin_lock_irq(&ssc_p->lock); - if (ssc_p->dir_mask & dir_mask) { - spin_unlock_irq(&ssc_p->lock); + if (ssc_p->dir_mask & dir_mask) return -EBUSY; - } + ssc_p->dir_mask |= dir_mask; - spin_unlock_irq(&ssc_p->lock); return 0; } @@ -355,7 +349,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, dir_mask = 1 << dir; - spin_lock_irq(&ssc_p->lock); ssc_p->dir_mask &= ~dir_mask; if (!ssc_p->dir_mask) { if (ssc_p->initialized) { @@ -369,7 +362,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, ssc_p->cmr_div = ssc_p->tcmr_period = ssc_p->rcmr_period = 0; ssc_p->forced_divider = 0; } - spin_unlock_irq(&ssc_p->lock); /* Shutdown the SSC clock. */ pr_debug("atmel_ssc_dai: Stopping clock\n"); diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h index ae764cb541c7..3470b966e449 100644 --- a/sound/soc/atmel/atmel_ssc_dai.h +++ b/sound/soc/atmel/atmel_ssc_dai.h @@ -93,7 +93,6 @@ struct atmel_ssc_state { struct atmel_ssc_info { char *name; struct ssc_device *ssc; - spinlock_t lock; /* lock for dir_mask */ unsigned short dir_mask; /* 0=unused, 1=playback, 2=capture */ unsigned short initialized; /* true if SSC has been initialized */ unsigned short daifmt; -- 2.23.0

2 1

[alsa-devel] [PATCH] ASoC: atmel_ssc_dai: Remove wrong spinlock usage
by Gregory CLEMENT 18 Sep '19

18 Sep '19

A potential bug was reported in the email "[BUG] atmel_ssc_dai: a possible sleep-in-atomic bug in atmel_ssc_shutdown"[1] Indeed in the function atmel_ssc_shutdown() free_irq() was called in a critical section protected by spinlock. However this spinlock is only used in atmel_ssc_shutdown() and atmel_ssc_startup() functions. After further analysis, it occurred that the call to these function are already protected by mutex used on the calling functions. Then we can remove the spinlock which will fix this bug as a side effect. Thanks to this patch the following message disappears: "BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909" [1]: https://www.spinics.net/lists/alsa-devel/msg71286.html Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> --- sound/soc/atmel/atmel_ssc_dai.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index 6f89483ac88c..365957e86419 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -116,19 +116,16 @@ static struct atmel_pcm_dma_params ssc_dma_params[NUM_SSC_DEVICES][2] = { static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = { { .name = "ssc0", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[0].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, { .name = "ssc1", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[1].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, { .name = "ssc2", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[2].lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, }, @@ -317,13 +314,11 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, snd_soc_dai_set_dma_data(dai, substream, dma_params); - spin_lock_irq(&ssc_p->lock); if (ssc_p->dir_mask & dir_mask) { spin_unlock_irq(&ssc_p->lock); return -EBUSY; } ssc_p->dir_mask |= dir_mask; - spin_unlock_irq(&ssc_p->lock); return 0; } @@ -355,7 +350,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, dir_mask = 1 << dir; - spin_lock_irq(&ssc_p->lock); ssc_p->dir_mask &= ~dir_mask; if (!ssc_p->dir_mask) { if (ssc_p->initialized) { @@ -369,7 +363,6 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, ssc_p->cmr_div = ssc_p->tcmr_period = ssc_p->rcmr_period = 0; ssc_p->forced_divider = 0; } - spin_unlock_irq(&ssc_p->lock); /* Shutdown the SSC clock. */ pr_debug("atmel_ssc_dai: Stopping clock\n"); -- 2.23.0

2 2

[alsa-devel] alsa acting up
by liebrecht＠grossmann-venter.com 18 Sep '19

18 Sep '19

See images in links. 1) "http://grossmann-venter.com/visitors/ug/alsa/alsa-pulse-181vsl_unplug.png" 2) "http://grossmann-venter.com/visitors/ug/alsa/alsa-dont recognize1818VSLpng" 1) As soon as pulseaudio is started Alsa says 1818VSL is unplugged....? 2) Clearly Presonus 1818VSL is found as lsusb output says, but alsa has no clue about it. How do I get alsa to recognise 181VSL as it is found by lsusb so it is presnet on the system. It used to work fine but alsa just stopped working with 1818VSL recently for no reason. I know this is a developers group, but please at least answer where I can get help. Alsa help is absolutely non-existing. I also posted a bug with no response in another thread. Thanks.

1 0

[alsa-devel] [PATCH v5 0/5] Add HDMI jack support on RK3288
by Cheng-Yi Chiang 18 Sep '19

18 Sep '19

This patch series supports HDMI jack reporting on RK3288, which uses DRM dw-hdmi driver and hdmi-codec codec driver. The previous discussion about reporting jack status using hdmi-notifier and drm_audio_component is at https://lore.kernel.org/patchwork/patch/1083027/ The new approach is to use a callback mechanism that is specific to hdmi-codec. Changes from v4 to v5: - synopsys/Kconfig: Remove the incorrect dependency change in v4. - rockchip/Kconfig: Add dependency of hdmi-codec when it is really need for jack support. Cheng-Yi Chiang (5): ASoC: hdmi-codec: Add an op to set callback function for plug event drm: bridge: dw-hdmi: Report connector status using callback drm: dw-hdmi-i2s: Use fixed id for codec device ASoC: rockchip_max98090: Add dai_link for HDMI ASoC: rockchip_max98090: Add HDMI jack support .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 13 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 41 ++++++- include/drm/bridge/dw_hdmi.h | 4 + include/sound/hdmi-codec.h | 17 +++ sound/soc/codecs/hdmi-codec.c | 46 +++++++ sound/soc/rockchip/Kconfig | 3 +- sound/soc/rockchip/rk3288_hdmi_analog.c | 3 +- sound/soc/rockchip/rockchip_max98090.c | 116 ++++++++++++++---- 8 files changed, 216 insertions(+), 27 deletions(-) -- 2.22.0.510.g264f2c817a-goog

4 12

[alsa-devel] alsa acting up
by liebrecht＠grossmann-venter.com 18 Sep '19

18 Sep '19

See images in links. 1) "http://grossmann-venter.com/visitors/ug/alsa/alsa-pulse-181vsl_unplug.png" 2) "http://grossmann-venter.com/visitors/ug/alsa/alsa-dont recognize1818VSLpng" 1) As soon as pulseaudio is started Alsa says 1818VSL is unplugged....? 2) Clearly Presonus 1818VSL is found as lsusb output says, but alsa has no clue about it. How do I get alsa to recognise 181VSL as it is found by lsusb so it is presnet on the system. It used to work fine but alsa just stopped working with 1818VSL recently for no reason. I know this is a developers group, but please at least answer where I can get help. Alsa help is absolutely non-existing. I also posted a bug with no response in another thread. Thanks.

1 0

Re: [alsa-devel] Alsa-devel Digest, Vol 149, Issue 28
by Channaiah Vanitha (RBEI/ECF3) 18 Sep '19

18 Sep '19

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

1 0

Re: [alsa-devel] [PATCH 2/3] ASoC: fsl_asrc: update supported sample format
by S.j. Wang 18 Sep '19

18 Sep '19

Hi > > On Fri, Sep 13, 2019 at 05:48:40AM +0000, S.j. Wang wrote: > > Hi > > > > > > > > On Tue, Sep 10, 2019 at 02:07:25AM +0000, S.j. Wang wrote: > > > > > On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote: > > > > > > The ASRC support 24bit/16bit/8bit input width, so S20_3LE > > > > > > format should not be supported, it is word width is 20bit. > > > > > > > > > > I thought 3LE used 24-bit physical width. And the driver assigns > > > > > ASRC_WIDTH_24_BIT to "width" for all non-16bit cases, so 20-bit > > > > > would go for that 24-bit slot also. I don't clearly recall if I > > > > > had explicitly tested S20_3LE, but I feel it should work since I put > there... > > > > > > > > For S20_3LE, the width is 20bit, but the ASRC only support 24bit, > > > > if set the ASRMCR1n.IWD= 24bit, because the actual width is 20 > > > > bit, the volume is Lower than expected, it likes 24bit data right shift 4 > bit. > > > > So it is not supported. > > > > > > Hmm..S20_3LE right-aligns 20 bits in a 24-bit slot? I thought > > > they're left aligned... > > > > > > If this is the case...shouldn't we have the same lower-volume > > > problem for all hardwares that support S20_3LE now? > > > > Actually some hardware/module when they do transmission from FIFO to > > shift register, they can select the start bit, for example from the > > 20th bit. but not all module have this capability. > > > > For ASRC, it haven't. IWD can only cover the data width, there is no > > Other bit for slot width. > > Okay..let's drop the S20_3LE then. But would it be possible for you to > elaborate the reasoning into the commit message also? Just for case when > people ask why we remove it simply. > > Thanks OK. Best regards Wang shengjiu

1 0