The 'Empty "${var:MonoSpeaker}"' part can only every succeed if we do:
Define.MonoSpeaker ""
But so far that would result in an error like this one:
ALSA lib ucm_subs.c:367:(uc_mgr_get_substituted_value) variable '${var:MonoSpeaker}' is not defined in this context!
ALSA lib main.c:983:(snd_use_case_mgr_open) error: failed to import cht-bsw-rt5672 use case configuration -22
alsaucm: error failed to open sound card cht-bsw-rt5672: Invalid argument
This commit fixes this by allowing empty values for "${var:...}"
substitutions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Mark Hills [Mon, 22 Jun 2020 13:15:10 +0000 (14:15 +0100)]
dsnoop: The delay presented to snd_pcm_status_delay() was incorrect
This was the original bug that caused me to start looking at the
ring buffer functions.
In the API this is documented as:
"Delay is distance between current application frame position and
sound frame position. It's positive and less than buffer size in
normal situation, negative on playback underrun and greater than
buffer size on capture overrun. "
Because dsnoop was returning the buffer space available to the hardware
the return value was always quite large, and moved in the wrong
direction.
With this patch, dsnoop now gives results which are comparable to using
the "hw" device directly. My test case was with snd-echo3g (Layla3G).
Signed-off-by: Mark Hills <mark@xwax.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mark Hills [Mon, 22 Jun 2020 13:15:08 +0000 (14:15 +0100)]
control: Fix a bug that prevented namehint behaviour
Looks like the documented behaviour was broken in commit 1ba513f9 in
2006, with the introduction of multiple fields.
I've chosen to match the described behaviour. Prior to this patch,
using namehint could be made to work by exploiting the lack of escaping
of the "name", populating the other fields:
"plug:front|DESCDo all conversions for front speakers"
rather than that which is documented and presumed to be the intention
for asoundrc files:
"plug:front|Do all conversions for front speakers"
Everything seems to strongly suggest nobody is using this feature; I can
find no working examples through a web search and probably someone
would have hit this bug. It's not documented in configuration, only in
the snd_device_name_hint() call. So it would probably clutter things to
provide compatibility for the old behaviour.
I have found it to be very useful since working in Chromium, where it is
the only way to expose chosen ALSA devices to web applications.
A temporary buffer is required to null-terminate the string. I see no
use of alloca() in the code, presumably to avoid unbounded stack size.
So memory is allocated on the heap.
Signed-off-by: Mark Hills <mark@xwax.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Harald van Dijk [Tue, 16 Jun 2020 17:53:57 +0000 (18:53 +0100)]
pcm: dmic: assembly: add x32 support.
x32 is the x86_64 ABI that uses 32-bit pointers, so requires loading
addresses into edi/esi/ebx rather than rdi/rsi/rbx.
Note that instructions such as movl %eax, (%rdi) do not require
updating, as loading an address into %edi zeroes the high bits, causing
the full %rdi register to hold a valid address.
Signed-off-by: Harald van Dijk <harald@gigawatt.nl> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Feature 'variable periodsize' allows to extend user period size up to
buffer_size/2 independent of slave period. On enlargement of the settings
for period_time.max and period_size.max the setting for openmax
was not updated.
This lead to the effect, that if the slave period itself had openmax
set it was still set on the extended size. Configuration of a period
matching half buffer size was thus rejected.
Example for failure: period size of 384 (half buffer size) is requested
which is rejected and rounded down to 352:
PERIOD_SIZE: [32 352]
BUFFER_SIZE: [64 768]
When correctly applying the openmax setting:
PERIOD_SIZE: [32 384]
BUFFER_SIZE: [64 768]
Signed-off-by: Andreas Pape <apape@de.adit-jv.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
John Keeping [Tue, 16 Jun 2020 18:29:30 +0000 (19:29 +0100)]
control: ctlparse - use type-specific bound on element count
Using a fixed bound of 128 means that too many values may be set for an
INTEGER64 type and that any elements past 128 are out of reach for BYTE
type controls.
Derive the maximum number of elements from the type so that the full
range is parsed for all types.
Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
pcm: Fix memory leak at snd_pcm_new when THREAD_SAVE_API is defined
The pthread_mutexattr_t object should be destroyed by calling
pthread_mutexattr_destroy(), otherwise it may cause a potential
memory leak due to the different implement of pthread_mutexattr_init()
Signed-off-by: chunxu.li <chunxuxiao@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Jaroslav Kysela [Thu, 4 Jun 2020 16:22:59 +0000 (18:22 +0200)]
snd_dlopen: do not use absolute plugin path for snd_dlopen() calls
In commit b906db19ef9f4fb7886003072e550391cc1ac651, the snd_dlopen()
implements the automatic lookup to the ALSA_PLUGIN_DIR directory.
It is not necessary to add the absolute paths in callers now.
The plugin names are also searched in ld.so.conf paths as the fallback now,
but it should not be a big problem.
Jaroslav Kysela [Tue, 26 May 2020 16:54:31 +0000 (18:54 +0200)]
ucm: implement the toplevel ucm configuration file parser
There is a big issue to validate all possible configuration paths.
Let create ucm2/ucm.conf file which describe the lookups. It may
be also customized later to follow the kernel-side development.
Jaroslav Kysela [Tue, 19 May 2020 14:48:43 +0000 (16:48 +0200)]
ucm: configuration - add DefineRegex
Syntax:
DefineRegex.VariableName {
String "something to match"
Regex "(me)thi(ng)"
}
Result:
- configuration variable "VariableName" is equal to "mething"
- configuration variable "VariableName1" is equal to "me"
- configuration variable "VariableName2" is equal to "ng"
Notes:
The "Flags" string in the DefineRegex compound may specify
the compilation flags (e = extended, i = ignore case,
s = no substitutes, n = newline). See 'man 3 regex' for
more details.
Jaroslav Kysela [Thu, 14 May 2020 14:12:23 +0000 (16:12 +0200)]
ucm: execute SectionDefaults lately (when the first verb is set)
We need a way to set the SectionOnce at first before SectionDefaults.
It also does not make sense to run SectionDefaults when the API is
used only to query for values or so.
Execute the SectionDefaults commands only when the first verb
is set (before the verb specific commands).
Takashi Iwai [Mon, 11 May 2020 14:31:14 +0000 (16:31 +0200)]
pcm: rate: Fix uninitialized variable warning
The recent gcc warning indicates the uninitialized variable commit_err:
pcm_rate.c:1104:6: warning: ‘commit_err’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (commit_err < 0)
^
Add a proper initialization to commit_err.
Fixes: 29041c522071 ("fix infinite draining of the rate plugin in SND_PCM_NONBLOCK mode") Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Mon, 11 May 2020 14:27:31 +0000 (16:27 +0200)]
pcm: rate: Fix compile warning wrt bit ops and comparison
We've got a gcc warning:
pcm_rate.c: In function ‘snd_pcm_rate_drain’:
pcm_rate.c:1090:19: warning: suggest parentheses around comparison in operand of ‘&’ [-Wparentheses]
if (pcm->mode & SND_PCM_NONBLOCK != 0) {
^
Drop the zero comparison for fixing the warning and for simplicity.
Fixes: 29041c522071 ("fix infinite draining of the rate plugin in SND_PCM_NONBLOCK mode") Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jaroslav Kysela [Thu, 7 May 2020 14:38:29 +0000 (16:38 +0200)]
conf: change namehint for pcm.front
It seems that we have regressions for pcm.front (some
applications are using this device also for the default
raw input). Change the description and allow both
directions.
Fixes: https://github.com/alsa-project/alsa-lib/issues/39 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Takashi Iwai [Wed, 6 May 2020 20:40:16 +0000 (22:40 +0200)]
header: Fix build error with old kernel headers
Old development environment doesn't necessarily contain the headers
defining __kernel_long_t that is recently used for y2038 timespec
conditional. Define it explicitly in such a case.
Newer versions of GCC (> 5.0) accept that ebx is declared
in the clobber list even in PIC mode. Meanwhile, even
unlikely, the compiler may use ebx as base address of
one of the memory entry, making subsequent access to
them unreliable ('size', 'dst_step', 'src_step', 'sum_step').
Adding ebx in the clobber solves the problem.
By the way, the entry 'old_ebx' is no longer required.
git://git.alsa-project.org / alsa-lib.git / log