When dmix uses non-interleaved mixing mode the offset and step width
to sum_buffer was calculated by using the dmix channels instead of
the slave channels. This leads to audio distortions due to frame
corruption.
example:
- With below configuratio, Do aplay on both device in parallel for
audio distortion
pcm.dmix_2_channels {
type dmix
ipc_key 5678293
ipc_perm 0660
ipc_gid audio
bindings [0 1]
slave {
pcm "hardware"
channels 2
periods 4
period_time 40000
}
}
pcm.dmix_1_channels {
type dmix
ipc_key 5678293
ipc_perm 0660
ipc_gid audio
bindings [0]
slave {
pcm "hardware"
channels 1
periods 4
period_time 40000
}
}
pcm.hardware {
type hw
card 0
channels 2
rate 48000
format S16_LE
}
Signed-off-by: Vijay Palaniswamy <vijay.palaniswamy@in.bosch.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both USB audio cards on Lenovo ThinkStation P620 don't support IEC958,
so disable IEC958 accordingly.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This mimics snd_pcm_create_iec958_consumer in the kernel.
The rate and wordlength bits will only be modified if they are
set to "not indicated", which is now the default if no status
option is used.
This allows applications to override parameters determined from
the stream or implement channel status bits extensions without
needing to change pcm_iec958 code.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
High bitrate compressed audio data like DTS HD or MAT is usually
packed into 8-channel data. The HDMI specs state this has to be
formatted as a single IEC958 stream, compared to normal multi-
channel PCM data which has to be formatted as parallel IEC958 streams.
As this single-stream formatting mode may break existing setups that
expect non-PCM multichannel data to be formatted as parallel IEC958
streams it needs to be explicitly selected by setting the hdmi_mode
option to true.
The single-stream formatting implementation is prepared to cope with
arbitrary channel counts but only limited testing was done for channel
counts other than 8.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As Maarten Baert recently reported, the current dmix code applies the
semaphore unnecessarily around mixing streams even when the lockless
mix operation is used on x86. This was rather introduced mistakenly
at the commit 267d7c7281 ("Add support of little-endian on
i386/x86_64 dmix") where the generic dmix code was included on x86,
too.
For achieving the original performance back, this patch changes the
semaphore handling to be checked at run time instead of statically at
compile time.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recently reported (but a long-standing) bug about the
unconditional semaphore usage in the dmix implies that basically we've
had no problem with the locking in the practical usages over years.
Although the lockless operation has a clear merit, it's a much higher
CPU usage (especially on some uncached pages), and it might lead to a
potential deadlock in theory (which is hard to reproduce at will,
though).
This patch introduces a new configure option "--enable-lockless-dmix"
or "--disable-lockless-dmix" to let user choose the default dmix
operation mode. The usage of the lockless mixing has been already
conditionally enabled via asoundrc and card config
"direct_memory_access", so we just need to set the default value based
on it.
In this patch, the default is set off to the lockless mixing, i.e. the
generic mixing is chosen. It makes more sense from the performance
POV. For any users who still require the lockless operation, it can
be enabled either via configure option or the asoundrc.
The magic number used in the shmem is also changed depending on the
operation mode. It's just for safety, not to conflict both operation
modes with each other.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In documentation, there're two ways relevant to the identifier of control
element. However, the case of combination has the lack of parameters.
This commit improves documentation in this point.
Fixes: f3c24de8c0 ("ctl: add an overview for design of ALSA control interface")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
We need to define the common shared configuration like for multiple
HDMI devices or so. Substitute the whole merged configuration tree
including identifiers.
Fixes: https://github.com/alsa-project/alsa-lib/issues/67
Fixes: dcef48f13d
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Recent ucm-conf changes introduce checks like this one in various places:
If.mspk {
Condition {
Type String
Empty "${var:MonoSpeaker}"
}
True ...
False ...
}
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>
I took time to understand these functions in the context of the
rest of the code, which would have been a lot quicker with a comment
like this.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Match the equivalent funciton for playback. This is on the assumption
that values should be capped at zero, which is what _rewindable()
implements.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This looks like a simple mistake dating back to 2003 (commit 7470a5b9)
where code originated from dmix.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The previous implementation would mean that stop_threshold behaved
erratically. The intent is to detect that the buffer is too full,
and stop.
In practice, I don't think this was a bug in practice for applications
which don't adjust the stop_threshold. The line above catches those cases.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
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>
Ths "namehint" is a list, and there doesn't seem to have been any
history where the separator would be a colon.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There's been some recent action to move the distribution-default setup
from /etc to /usr/etc, and we should follow that, too.
This patch adds /usr/etc/alsa.conf.d and /usr/etc/alsa.conf to the
default search paths.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The extplug sets incorrectly the timestamping type to
gettimeofday. Copy the timestamp type from the slave pcm
as other plugins do.
The problem is visible when the
"pcm: dmix: fix sw_params handling of timestamp types in direct plugins"
patch was applied for the direct plugins.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1847508
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The syntax is ${CardNumberByName:CARDNAME[#INDEX]}.
The CARDNAME is the ALSA's soundcard name (short form).
The INDEX is the instance (0 = first, 1 = second etc.).
Example: ${CardNumberByName:HDA Intel PCH}
(which is identical to ${CardNumberByName:HDA Intel PCH#0})
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Example (set variable 'Module' to the kernel module name for the given card):
Define.SysfsPath "class/sound/card${CardNumber}/device/driver"
Define.Module "${sys:$SysfsPath}"
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
It may be useful to ignore the errors where the environment
or sysfs values are not defined for the specific hardware.
Enhance substitution for 'syntax 3' so $${} substitution
means ignore the errors (return an empty string).
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
snd_dlobj_cache_cleanup() function frees snd_libdir_origin, but
the pointer may be used again in snd_dlpath().
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1847508
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
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>
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>
There is a case where the original array has already new indexes
(the merged array is placed before the original nodes).
Set the temporary index string identifiers to unique strings.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Both headset and speaker on HP Thunderbolt Dock don't support IEC958
interface.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
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>
