June 2010 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Routing irq throw a gpio using the wm9713
by Michael Trimarchi 18 Aug '10

18 Aug '10

Hi all, I'm trying to rise an irq using irq2 of the wm9713 so I have configured the codec like this: #define GPIO2 (1 << 2) #define GPIO6 (1 << 6) /* Enable Interrupt Output enable on GPIO02 */ reg = codec->read(codec, AC97_MISC_AFE); codec->write(codec, AC97_MISC_AFE, reg & ~GPIO02); reg = codec->read(codec, AC97_GPIO_CFG); codec->write(codec, AC97_GPIO_CFG, reg & ~GPIO02); reg = codec->read(codec, AC97_GPIO_STICKY); codec->write(codec, AC97_GPIO_STICKY, reg | GPIO06); reg = codec->read(codec, AC97_GPIO_WAKEUP); codec->write(codec, AC97_GPIO_WAKEUP, reg | GPIO06); Then create a soc-jack on a gpio that is wired with the gpio6 of the codec. I don't received any interrupt Michael Trimarchi

1 1

[alsa-devel] [PATCH]alsa:patch_realtek.c Add support for the MacBookAir1, 1
by Justin P. Mattock 30 Jul '10

30 Jul '10

This patch adds support for the MacBookAir1,1 Note:I do not have this machine on hand only the codec#0 file for the machine.. located at https://bugs.launchpad.net/mactel-support/+bug/268301 So please test if you have the appropriate equipment, and report any issues to the alsa devel list (alsa-devel(a)alsa-project.org). Signed-off-by: Justin P. Mattock <justinmattock(a)gmail.com> --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 + sound/pci/hda/patch_realtek.c | 59 +++++++++++++++++++++++++- 2 files changed, 58 insertions(+), 2 deletions(-) diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 1d38b0d..d3838b5 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -125,6 +125,7 @@ ALC882/883/885/888/889 macpro MacPro support mb5 Macbook 5,1 macmini3 Macmini 3,1 + mba11 MacBook Air 1,1 mba21 Macbook Air 2,1 mbp3 Macbook Pro rev3 imac24 iMac 24'' with jack detection diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index fc767b6..1dcf78c 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -209,6 +209,7 @@ enum { ALC882_ASUS_A7J, ALC882_ASUS_A7M, ALC885_MACPRO, + ALC885_MBA11, ALC885_MBA21, ALC885_MBP3, ALC885_MB5, @@ -7444,6 +7445,13 @@ static struct snd_kcontrol_new alc885_mba21_mixer[] = { { } }; +/* MacBookAir1,1 not sure what/where things are(dont have the machine). */ + +static struct snd_kcontrol_new alc885_mba11_mixer[] = { + HDA_CODEC_VOLUME("Speaker Playback Volume", 0x0c, 0x00, HDA_OUTPUT), + HDA_BIND_MUTE("Speaker Playback Switch", 0x0c, 0x02, HDA_OUTPUT), + { } +}; static struct snd_kcontrol_new alc885_mbp3_mixer[] = { HDA_CODEC_VOLUME("Speaker Playback Volume", 0x0c, 0x00, HDA_OUTPUT), @@ -7929,6 +7937,40 @@ static struct hda_verb alc885_mba21_init_verbs[] = { { } }; +static struct hda_verb alc885_mba11_init_verbs[] = { + /*Internal and HP Speaker Mixer*/ + {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO}, + {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, + /* Main Speaker */ + {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, (PIN_OUT | AC_PINCTL_VREF_50) }, + {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + {0x14, AC_VERB_SET_CONNECT_SEL, 0x00}, + /* HP jack */ + {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, 0xc4}, + {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + {0x15, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x15, AC_VERB_SET_UNSOLICITED_ENABLE, (ALC880_HP_EVENT | AC_USRSP_EN)}, + /* FIXME: Line in? (as well as the mic). */ + {0x17, AC_VERB_SET_PIN_WIDGET_CONTROL, AC_PINCTL_VREF_50}, + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE}, + /* 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In */ + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + /* 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In */ + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + /* 0x24 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In */ + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + { } +}; /* Macbook Pro rev3 */ static struct hda_verb alc885_mbp3_init_verbs[] = { @@ -9298,6 +9340,7 @@ static const char *alc882_models[ALC882_MODEL_LAST] = { [ALC885_MACPRO] = "macpro", [ALC885_MB5] = "mb5", [ALC885_MACMINI3] = "macmini3", + [ALC885_MBA11] = "mba11", [ALC885_MBA21] = "mba21", [ALC885_MBP3] = "mbp3", [ALC885_IMAC24] = "imac24", @@ -9478,7 +9521,7 @@ static struct snd_pci_quirk alc882_ssid_cfg_tbl[] = { SND_PCI_QUIRK(0x106b, 0x2c00, "MacbookPro rev3", ALC885_MBP3), SND_PCI_QUIRK(0x106b, 0x3000, "iMac", ALC889A_MB31), SND_PCI_QUIRK(0x106b, 0x3200, "iMac 7,1 Aluminum", ALC882_ASUS_A7M), - SND_PCI_QUIRK(0x106b, 0x3400, "MacBookAir 1,1", ALC885_MBP3), + SND_PCI_QUIRK(0x106b, 0x3400, "MacBookAir 1,1", ALC885_MBA11), SND_PCI_QUIRK(0x106b, 0x3500, "MacBookAir 2,1", ALC885_MBA21), SND_PCI_QUIRK(0x106b, 0x3600, "Macbook 3,1", ALC889A_MB31), SND_PCI_QUIRK(0x106b, 0x3800, "MacbookPro 4,1", ALC885_MBP3), @@ -9542,7 +9585,19 @@ static struct alc_config_preset alc882_presets[] = { .input_mux = &alc882_capture_source, .dig_out_nid = ALC882_DIGOUT_NID, }, - [ALC885_MBA21] = { + [ALC885_MBA11] = { + .mixers = { alc885_mba11_mixer }, + .init_verbs = { alc885_mba11_init_verbs, alc880_gpio1_init_verbs }, + .num_dacs = 2, + .dac_nids = alc882_dac_nids, + .channel_mode = alc885_mba21_ch_modes, + .num_channel_mode = ARRAY_SIZE(alc885_mba21_ch_modes), + .input_mux = &alc882_capture_source, + .unsol_event = alc_automute_amp_unsol_event, + .setup = alc885_mbp3_setup, + .init_hook = alc_automute_amp, + }, + [ALC885_MBA21] = { .mixers = { alc885_mba21_mixer }, .init_verbs = { alc885_mba21_init_verbs, alc880_gpio1_init_verbs }, .num_dacs = 2, -- 1.7.1.rc1.21.gf3bd6

2 2

[alsa-devel] [PATCH] Two patches for Alsa-plugins (pulse)
by David Henningsson 29 Jul '10

29 Jul '10

These two patches are being used in Ubuntu Lucid (released this April) and are working well enough to have people asking us to backport them to Karmic. Today I got an email, asking for the upstream status of one of these patches, since he wanted them in Fedora. If posting them here isn't the correct way to upstream them, please tell me so. The first one (Fix invalid buffer pointer return value) fixes broken logic: This patch improves recovering from underruns, and prevents hangs inside snd_pcm_write* and snd_pcm_read* due to snd_pcm_avail* returning too low values. It especially helps low latency situations. The second one (Do not report underruns to the ALSA layer) is more a change of behavior, which could be questioned. The arguments for removing that code are these: * If pulseaudio gets an underrun, the normal way to end that underrun is to feed it with more buffers. This is different from the ALSA way of dealing with underruns, which requires hardware buffer pointers to be reset. * In addition, underrun signals are delivered asynchronously from pulseaudio. This means that there might be more buffers on the way to pulseaudio when the underrun is reported, making the underrun obsolete. Unfortunately, there is currently no known way to determine whether this is the case or not. // David

5 20

[alsa-devel] [PATCH] Ensure codec patch files are checked for the correct codec ID
by David Henningsson 26 Jul '10

26 Jul '10

This one just popped out when I read the source code - or is there a reason for parsing vendorid and subid without caring about the result? // David

4 5

[alsa-devel] [PATCH 1/4] ASoC: DaVinci: remove requirement that dma_params is 1st in structure
by Troy Kisky 13 Jul '10

13 Jul '10

Remove requirement that dma_params is 1st in the structures davinci_audio_dev and davinci_mcbsp_dev. Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> --- sound/soc/davinci/davinci-i2s.c | 6 +----- sound/soc/davinci/davinci-mcasp.c | 1 + sound/soc/davinci/davinci-mcasp.h | 5 ----- sound/soc/davinci/davinci-pcm.c | 7 ++++--- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index 4ae7070..9e69a4e 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -98,11 +98,6 @@ enum { }; struct davinci_mcbsp_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; #define MOD_DSP_A 0 @@ -547,6 +542,7 @@ static int davinci_i2s_probe(struct platform_device *pdev) dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res->start; davinci_i2s_dai.private_data = dev; + davinci_i2s_dai.dma_data = dev->dma_params; ret = snd_soc_register_dai(&davinci_i2s_dai); if (ret != 0) goto err_free_mem; diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 5d1f98a..5023915 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -907,6 +907,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dma_data->channel = res->start; davinci_mcasp_dai[pdata->op_mode].private_data = dev; + davinci_mcasp_dai[pdata->op_mode].dma_data = dev->dma_params; davinci_mcasp_dai[pdata->op_mode].dev = &pdev->dev; ret = snd_soc_register_dai(&davinci_mcasp_dai[pdata->op_mode]); diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/davinci/davinci-mcasp.h index 9d179cc..582c924 100644 --- a/sound/soc/davinci/davinci-mcasp.h +++ b/sound/soc/davinci/davinci-mcasp.h @@ -39,11 +39,6 @@ enum { }; struct davinci_audio_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; int sample_rate; diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index c73a915..c2c2e85 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -238,10 +238,11 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream) struct davinci_runtime_data *prtd; int ret = 0; struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->private_data; - struct davinci_pcm_dma_params *params = &pa[substream->stream]; - if (!params) + struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->dma_data; + struct davinci_pcm_dma_params *params; + if (!pa) return -ENODEV; + params = &pa[substream->stream]; snd_soc_set_runtime_hwparams(substream, &davinci_pcm_hardware); /* ensure that buffer size is a multiple of period size */ -- 1.5.6.3

3 5

[alsa-devel] How does struct snd_pcm_hardware relate to the actual hardware
by Adam Rosenberg 12 Jul '10

12 Jul '10

I am using DMA to transfer data to SPORT1 on my Blackfin BF537. I am using a CS42448 CODEC that has 8 DACs. I am using TDM mode and have set the following: DMA Buffer Size For Each SPORT Data Line (Rx or Tx) = 131072 bytes DMA Periods = 8 static struct snd_pcm_hardware snd_pcm_hw = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_RESUME), .formats = SNDRV_PCM_FMTBIT_S32_LE, .rates = SNDRV_PCM_RATE_48000, .rate_min = 48000, .rate_max = 48000, .buffer_bytes_max = 32768, .channels_min = 2, .channels_max = 2, .period_bytes_min = 8, .period_bytes_max = 4096, .periods_min = 8, .periods_max = 8, }; Everytime I receive a DMA interrupt from the SPORT driver I call snd_pcm_period_elapsed for all of the substreams that are currently active. In the PCM Copy callback I calculate the position within the DMA buffer to write to based on the TDM slot for the channel and the position passed into the function. The audio is not being placed into the DMA buffer properly. The audio plays faster than it should and has a constant stutter. I have read the "writing an ALSA driver" guide multiple times but it does not explain the relationship between struct snd_pcm_hardware, snd_pcm_period_elapsed, and the copy callback clearly enough for me to understand what I am doing wrong. Please explain how these interact in more detail to help me fix this problem. I can also send the full source code to the CS42448 driver I am working on if more details are needed. Thank you, Adam

2 2

[alsa-devel] Smart 5.1 function not working on VIA VT1708S with *three* jacks on mainboard
by Viliam Kubis 09 Jul '10

09 Jul '10

Hello, for quite some time the "Smart 5.1" function in alsa is not working properly when motherboard has only 3 audio jacks. Me and Raymond on alsa-bugtracker have been trying to solve the issue for a long time but were unsuccessful. Please take a look at this alsa bug ticket: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4895 It contains A LOT of info on the problem + steps that we tried, which included patching the code. Synthom : NO "Surround" , "Center" and "LFE" Control and switch with VT1708S on a motherboard with 3 audio jacks Also NO surround sound. speaker-test -c 4 -t wav -Dsurround40 Channels count (4) not available for playbacks: Invalid argument Setting of hwparams failed: Invalid argument Please advise if you can. Thank you Best Regards Viliam Kubis -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

3 3

[alsa-devel] [RFC 00/16] ASoC: multi-component - CODECs
by Liam Girdwood 05 Jul '10

05 Jul '10

This is the second part of the multi-component series and focuses on the changes required to support ASoC multi-component on CODEC drivers. I've split the CODEC driver patches into smaller chunks and tried to group (where possible) similar CODECs together. All the patches will be rebased together at upstream time so we don't break bisect. Most CODEC drivers were extremely straight forward with changes limited to their probe() and remove() sections. Some CODECs did require a little extra work and this is marked in their commit messages. Thanks Liam

5 24

[alsa-devel] [RFC 0/5] ASoC multi-component support : core
by Liam Girdwood 05 Jul '10

05 Jul '10

ASoC is now coming up to it's 5th birthday and is beginning to show it's age a little when it comes to supporting the next generation of smart phones and multimedia devices with it's current single CODEC and single DMA platform design. Historically, ASoC is designed around an embedded sound card with a single CODEC and a single platform DMA driver (with multiple DAIs). This design works great for most of the current audio hardware in production, however we are now seeing hardware designs for the next generation of devices that can have many CODECs, DMAs, DSPs and a host of other audio peripherals connected to the audio subsystem. So we now need ASoC to support new audio hardware architectures with multiple audio CODECs, DMA engines, DSPs, DAIs etc. This patch series allows an ASoC sound card to support multiple components (CODECs, DAI and DMA) and is the first part in a series of work (other parts coming later in the year from Mark and I) designed to enhance ASoC for modern mobile audio hardware. This patch series provides the following important features:- 1) Allow sound cards to have multiple CODECs and platform DMA controllers. 2) Allow CODEC drivers to support more than one CODEC device. 3) Allow all CODEC, platform DMA and DAI drivers to have platform data. This is achieved by: - 1) Separating the component struct driver data from the component struct device data. 2) Making all components kernel devices. (A side effect of this change is that we can now store all our component private data in struct device private data (like everyone else) and there is also now less pointer indirection for components.) The change mainly affects only the probe() and remove() sections of component drivers and the component enumeration section of the core. The core also now handles setting up the CODEC data structs too (meaning CODEC drivers dont have to do this). All component PCM, DAPM and Kcontrol operations remain unchanged. I've so far tested the new multi-component enumeration on the TI OMAP and Marvell PXA platforms with AC97, MFD and I2C based CODECs. I do however need ASoC platform maintainers to test on their systems (as I only have a subset of the hardware). Some ASOC platforms do need a little extra checking/fixups too :- o Samsung platform: required the most work to untangle the components. o i.MX platform: required work to de-couple components. o Injenic J4740 platform: I do not have a toolchain to even build this arch so it will also need someone to build it too. If you find your platform does not work then the most likely reason is that I'm missing a platform_device registration for your CODEC, DAI, etc. device in your arch board.c or device.c files. Please let me know or send a patch :) All the multi-component code is in my multi-component branch here :- git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git This RFC post contains the changes to ASoC core only. I'll post the multi-component CODEC and platform changes as separate RFCs in order not to flood the list (as there are 38 patches in all). This patch series will eventually be rebased into a single patch for upstream so we dont break bisect. The subsequent patches for CODECs and platforms in this series can be found in the git branch above. The intention is to upstream this for 2.6.36 Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

5 14

[alsa-devel] [PATCH] ALSA: pcm_lib: avoid timing jitter in snd_pcm_read/write()
by David Dillow 05 Jul '10

05 Jul '10

When using poll() to wait for the next period -- or avail_min samples -- one gets a consistent delay for each system call that is usually just a little short of the selected period time. However, When using snd_pcm_read/write(), one gets a jittery delay that alternates between less than a millisecond and approximately two period times. This is caused by snd_pcm_lib_{read,write}1() transferring any available samples to the user's buffer and adjusting the application pointer prior to sleeping to the end of the current period. When the next period interrupt occurs, there is then less than avail_min samples remaining to be transferred in the period, so we end up sleeping until a second period occurs. This is solved by using runtime->twake as the number of samples needed for a wakeup in addition to selecting the proper wait queue to wake in snd_pcm_update_state(). This requires twake to be non-zero when used by snd_pcm_lib_{read,write}1() even if avail_min is zero. Signed-off-by: Dave Dillow <dave(a)thedillows.org> --- Hans, you may want this one as well for the SIS7019, as it gives more margin to deal with captured data on alternating calls into the stack. diff --git a/include/sound/pcm.h b/include/sound/pcm.h index dd76cde..83c6fa6 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -313,7 +313,7 @@ struct snd_pcm_runtime { struct snd_pcm_mmap_control *control; /* -- locking / scheduling -- */ - unsigned int twake: 1; /* do transfer (!poll) wakeup */ + snd_pcm_uframes_t twake; /* do transfer (!poll) wakeup if non-zero */ wait_queue_head_t sleep; /* poll sleep */ wait_queue_head_t tsleep; /* transfer sleep */ struct fasync_struct *fasync; diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index e9d98be..bcf95d3 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -287,8 +287,11 @@ int snd_pcm_update_state(struct snd_pcm_substream *substream, return -EPIPE; } } - if (avail >= runtime->control->avail_min) - wake_up(runtime->twake ? &runtime->tsleep : &runtime->sleep); + if (runtime->twake) { + if (avail >= runtime->twake) + wake_up(&runtime->tsleep); + } else if (avail >= runtime->control->avail_min) + wake_up(&runtime->sleep); return 0; } @@ -1707,7 +1710,7 @@ EXPORT_SYMBOL(snd_pcm_period_elapsed); * The available space is stored on availp. When err = 0 and avail = 0 * on the capture stream, it indicates the stream is in DRAINING state. */ -static int wait_for_avail_min(struct snd_pcm_substream *substream, +static int wait_for_avail(struct snd_pcm_substream *substream, snd_pcm_uframes_t *availp) { struct snd_pcm_runtime *runtime = substream->runtime; @@ -1757,7 +1760,7 @@ static int wait_for_avail_min(struct snd_pcm_substream *substream, avail = snd_pcm_playback_avail(runtime); else avail = snd_pcm_capture_avail(runtime); - if (avail >= runtime->control->avail_min) + if (avail >= runtime->twake) break; } _endloop: @@ -1820,7 +1823,7 @@ static snd_pcm_sframes_t snd_pcm_lib_write1(struct snd_pcm_substream *substream, goto _end_unlock; } - runtime->twake = 1; + runtime->twake = runtime->control->avail_min ? : 1; while (size > 0) { snd_pcm_uframes_t frames, appl_ptr, appl_ofs; snd_pcm_uframes_t avail; @@ -1833,7 +1836,9 @@ static snd_pcm_sframes_t snd_pcm_lib_write1(struct snd_pcm_substream *substream, err = -EAGAIN; goto _end_unlock; } - err = wait_for_avail_min(substream, &avail); + runtime->twake = min_t(snd_pcm_uframes_t, size, + runtime->control->avail_min ? : 1); + err = wait_for_avail(substream, &avail); if (err < 0) goto _end_unlock; } @@ -2042,7 +2047,7 @@ static snd_pcm_sframes_t snd_pcm_lib_read1(struct snd_pcm_substream *substream, goto _end_unlock; } - runtime->twake = 1; + runtime->twake = runtime->control->avail_min ? : 1; while (size > 0) { snd_pcm_uframes_t frames, appl_ptr, appl_ofs; snd_pcm_uframes_t avail; @@ -2060,7 +2065,9 @@ static snd_pcm_sframes_t snd_pcm_lib_read1(struct snd_pcm_substream *substream, err = -EAGAIN; goto _end_unlock; } - err = wait_for_avail_min(substream, &avail); + runtime->twake = min_t(snd_pcm_uframes_t, size, + runtime->control->avail_min ? : 1); + err = wait_for_avail(substream, &avail); if (err < 0) goto _end_unlock; if (!avail)

5 12