John Spencer [Sat, 15 Nov 2014 12:41:00 +0000 (13:41 +0100)]
snd_dlsym: only do versioning checks if built --with-versioning
a combination of some of the following garbage collecting LD/CFLAGS
-Os -g0 -fdata-sections -ffunction-sections -s -Wl,--gc-sections
-fno-unwind-tables -fno-asynchronous-unwind-tables
causes the symbol versioning marker symbols to be removed from BSS
since they're otherwise unreferenced. this causes dlsym failing to
find them which results in runtime breakage:
$ alsamixer
ALSA lib dlmisc.c:142:(snd_dlsym_verify) unable to verify version for symbol snd_config_hook_load
ALSA lib conf.c:3328:(snd_config_hooks_call) symbol snd_config_hook_load is not defined inside (null)
ALSA lib conf.c:3788:(snd_config_update_r) hooks failed, removing configuration
cannot open mixer: No such device or address
correct DSO:
$ objdump -T libasound.so.2.strip | grep _snd_config_hook_load_dlsym_config_hook_001 001196bc g DO .bss 00000001 _snd_config_hook_load_dlsym_config_hook_001
incorrect DSO:
$ objdump -T libs/libasound.so.2 | grep _snd_config_hook_load_dlsym_config_hook_001 00000000 g DO *ABS* 00000001 _snd_config_hook_load_dlsym_config_hook_001
since alsa was built with --without-versioning, doing those versioning
checks at all is unnecessary and harmful and thus now disabled in this case.
Signed-off-by: John Spencer <maillist-alsa@barfooze.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Thu, 6 Nov 2014 11:12:02 +0000 (12:12 +0100)]
pcm: dmix: Don't ignore SND_TIMER_EVENT_MSTOP
When a slave PCM gets an error like XRUN, it stops and notifies with
SND_TIMER_EVENT_MSTOP event. But the current code filters out this
type and eventually hang due to the empty timer queue. The fix is to
just add this event type to the filter bit mask.
hwdep: add missing declaration for snd_hwdep_poll_descriptors_count()
The alsa-lib has 'snd_hwdep_poll_descriptors_count()' but hwdep.h has no
declaration for the function. No applications can call the function just
by including the header.
This commit adds a line to the file for this function.
pcm: rewindable, forwardable: don't return stale data
The current behavior of snd_pcm_rewindable and snd_pcm_forwardable means
that the returned value is only accurate to one period. Or maybe even
meaningless if period interrupts are off. Fetch the up-to-date position
of the hardware pointer, as that's what is wanted by callers.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
pcm: handle negative values from snd_pcm_mmap_hw_avail
Such negative values can happen when an underrun happens and xrun
detection is disabled. Another situation is if the device updated the
pointer before alsa-lib has a chance to detect the xrun.
The problem is that these negative values could propagate to the
snd_pcm_rewindable return value, where it is specified that negative
returns must be interpreted as error codes and not as negative amount of
samples.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
pcm: express the rewind size limitation logic better
There are a few places where the argument of the .rewind or .forward
callback is checked against the same value as returned by .rewindable or
.forwardable. Express this "don't rewind more than rewindable" logic
explicitly, so that the future fixes to the rewindable size can go to
one function instead of two.
While at it, take advantage of the fact that snd_pcm_mmap_avail() cannot
return negative values (except due to integer overflow, which is AFAICS
impossible given the current boundary choice).
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
pcm: fix return value of snd_pcm_share_slave_avail
The return value was wrong for playback if slave->hw_ptr was near the
boundary and *pcm->appl.ptr was near zero. The wrong result was greater
than the boundary.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
pcm: fix snd_pcm_mmap_hw_avail() near the boundary
This function returned incorrect results when hw.ptr was near the
boundary and hw.appl_ptr was near zero. Here "incorrect" means "greater
than the boundary".
The result was incorrect, because it was used as a return value of
various *_rewindable() functions and also as the delay for ioplug.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 18 Aug 2014 09:45:17 +0000 (18:45 +0900)]
Sync enum snd_hwdep_iface_t with include/asound/asound.h
Some members in this enumerated type has not updated for 9 years, although
kernel-drivers added them during this period. This commit adds them following
to a commit 87df9f3 'sync include/asound/asound.h with 3.17-rc1 kernel'.
pcm: route: Use get32 for multi-source route calculation
The PCM route plugin can assign the destination value from average of
multiple sources with attenuation. This requires the read of each
channel value, sums and writes the resultant value in the requested
format.
Currently, get_labels is used for reading source values while
put32_labels is used for writing the dest value. This is, however,
a buggy implementation; get_labels gives the value as is only with
endianness and signedness conversions, but put32_labels assumes that
the value is normalized to 32bit int and it shifts down to the dest
format. In addition, the current code lacks get_labels entries for
the 24bit formats, as Shengjiu Wang spotted out.
For fixing these bugs, this patch replaces the read with
get32_labels and use always 64bit int for sum. This simplifies the
code a lot and drops many lines.
pcm: route: Use get/put labels for all 3 byte formats
So far, use_getput flag is set only when the src or dest format is
24bit physical width. But, also 18 and 20 bit physical width formats
should set the flag, too. This patch makes the check broader to cover
all 3 bytes formats.
pcm: Implement timestamp type handling in all plugins
Now all PCM plugins do support the proper timestamp type or pass it
over slaves. The internal monotonic flag is dropped and replaced with
tstamp_type in all places.
This patch implements the support for sw_params timestamp type in PCM
hw layer. As gettimestamp() is still unchanged, the resultant
timstamps may be still with CLOCK_MONOTONIC even if you pass monotonic
raw type. More fixes will follow.
pcm: Add sw_params API functions to get/set timestamp type
For obtaining / changing the timestamp type, add the corresponding
sw_params accessor API functions together with the public definitions
of timestamp types.
This patch only adds the functions and defines but doesn't bring the
functional changes yet.
Mark Brown [Tue, 8 Jul 2014 14:52:32 +0000 (16:52 +0200)]
pcm: Provide a CLOCK_MONOTONIC_RAW timestamp type
For applications which need to synchronise with external timebases such
as broadcast TV applications the kernel monotonic time is not optimal as
it includes adjustments from NTP and so may still include discontinuities
due to that. A raw monotonic time which does not include any adjustments
is available in the kernel from getrawmonotonic() so provide userspace with
a new timestamp type SNDRV_PCM_TSTAMP_TYPE_MONOTONIC_RAW which provides
timestamps based on this as an option.
Reported-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Phiree U2 has an unusual configuration. It only has S/PDIF output, but
there are still two devices presented:
- device 0: PCM audio, subject to volume control
- device 1: non-PCM data (passthrough), not subject to volume control
It looks like the AES bits are set according to the selected device,
since outputting PCM data via device 1 will not work (silence).
Currently only the device 0 is shown via the "iec958" alias, and the
second device is not accessible via hinted aliases.
Simply provide access to both of these devices via the "iec958" alias.
The M-Audio Delta 1010 card has 7.1 analog output, but no ready-made pcm
definition to use it.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Reported-and-tested-by: Matt Zagrabelny <mzagrabe@d.umn.edu> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tanu Kaskinen [Thu, 26 Jun 2014 10:30:25 +0000 (13:30 +0300)]
ucm: Document PlaybackPCMIsDummy and CapturePCMIsDummy values
At least PulseAudio needs special handling for dummy devices. To allow
that to happen automatically, the UCM configuration should contain the
information about which PCMs are dummy.
Sergey [Mon, 16 Jun 2014 15:52:51 +0000 (19:52 +0400)]
alsa-lib: pcm_plug: fix float conversion for user specified ttable
Move custom ttable with equal channels case from a separate ttable_last
exception into a common plugins insertion loop.
Fixes plug with ttable for float pcms (jack, ladspa).
Example: aplay -fFLOAT_LE /dev/zero
pcm.!default {
type plug
slave.pcm { type null }
ttable.0.0 1
}
Signed-off-by: Sergey <sergemp@mail.ru> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
pcm: rate: add rewindable and forwardable callbacks
This commit does not fix nonsense values returned by the rewind and
forward callbacks. E.g., with period_size = 1024 and buffer_size = 4096,
an attempt to rewind 1024 samples from the nearly-full buffer returns
4090.
Due to these nonsense values, the current rate plugin should be treated
as non-rewindable. That's why the new callbacks return 0.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Anssi Hannula [Sun, 8 Jun 2014 09:58:56 +0000 (12:58 +0300)]
pcm: Fix channel map query when there are lots of maps
On most HDA Intel HDMI devices, the channel map list is approx. 500 ints
in size, making the 256-sized buffer used by
snd_pcm_query_chmaps_from_hw() too small and causing the query to fail
(NULL result to caller, ENOMEM).
Matthias Larisch [Thu, 27 Mar 2014 18:05:10 +0000 (19:05 +0100)]
pcm: ladspa: Delay LADSPA plugin activate call
Some LADSPA Plugins rely on connected control ports on activate call.
While this is not okay by spec, the spec also encourages the activate
call happening as late as possible.
Takashi Iwai [Wed, 19 Mar 2014 09:52:24 +0000 (10:52 +0100)]
route: Fix invalid pointer access
An uninitialized chmap pointer value is assigned in
_snd_pcm_route_open(). Add NULL initializations appropriately, and
also avoid the possible invalid access of NULL pcmp pointer.
Takashi Iwai [Tue, 18 Mar 2014 14:23:09 +0000 (15:23 +0100)]
pcm: route: Don't handle no matching chmap as a serious error
When find_matching_chmap() returns an error for the non-matching
chmap, the caller, snd_pcm_route_open(), also returns an error
although it shouldn't be handled as the fatal error. This results in
the probe error with PulseAudio and it gives no real output in the
end.
The function snd_pcm_ioplug_hw_ptr_update() always increased the hw_ptr
by delta, without wrapping it to the boundary. This would lead to
problems when after many hours, the hw_ptr would overflow.
Signed-off-by: Luciano Montanaro <luciano.montanaro@magnetimarelli.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
conf: Allow 2.1 surround to use different number of channels
This way, cards that support LFE on four channels (e g laptop with
internal subwoofer) can do that, and other cards on a six channel setup
can use that as well.
Well, note that there is still a reference to "pcm.surround51" left here.
In practice, for HDA Intel sound cards this does not matter as both
surround51 and surround40 reference the same definition.
(And that's the only card I currently know of that actually does
surround2.1 over four channels.)
Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
pcm: route: Select slave chmap based on ttable information
It means we need to initialize this order:
1) Read the ttable to figure out which channels are present
2) Open slave pcm and find a matching chmap
3) Determine size of ttable (this can now depend on the chmap)
4) Read ttable coefficients
5) At prepare time, select the matching chmap
Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Maarten Baert [Wed, 26 Feb 2014 13:23:45 +0000 (14:23 +0100)]
pcm: Insert linear-to-float conversion when rate or channel count is incorrect
This fixes a bug where snd_pcm_plug_insert_plugins fails when both
client and slave use format float, but the rate or channel count does
not match. I also removed some redundant code.
Riku Voipio [Fri, 7 Feb 2014 13:38:58 +0000 (15:38 +0200)]
alsa-lib: heavy pcm atomics cleanup
The following patch comes from the realization that at least ARM code
for atomics is quite broken and nobody has cared for a decade.
A quick dive shows that only snd_atomic_{read,write}_{begin,end}
appear to be used widely. These are implemented using wmb/rmb.
Only other use of atomic functions is in pcm_meter.c.
The #SND_PCM_TYPE_METER plugin type appears rarely, if ever, used.
I presume these days anyone who wants a meter/scope will do in pulseaudio
layer instead of alsa.
It would seem better fit to have pcm_meter in alsa-plugins instead
of alsa-lib, but I guess that would be an ABI break...
So instead, I'm proposing here
1. Removal of all hand-crafted atomics from iatomic.h apart from barriers,
which are used in snd_atomic_{read,write}_{begin,end}.
2. Using __sync_synchronize as the default fallback for barriers. This
has been available since gcc 4.1, so it shouldn't be a problem.
3. Defining the few atomics used by pcm_meter.c withing pcm_meter.c
itself, using gcc atomic builtins[1].
4. Since gcc atomic builtins are available only since gcc 4.7, add a check for
that in gcc configure.in, and don't build pcm meter plugin if using
older gcc.
The last point has the impact, that if there actually is someone who 1)
uses the meter plugin 2) wants to upgrade to 2014 alsa-lib 3) but
does not want to use a 2012+ gcc - that someone will be inconvenienced.
Finally remove the unneeded configure check for cpu type. We can
trust the gcc to set right flags for us.
Olivier Langlois [Fri, 24 Jan 2014 00:03:00 +0000 (19:03 -0500)]
pcm: use CLOCK_REALTIME for non-monotonic ts
gettimeofday() is the same than clock_gettime(CLOCK_REALTIME)
except for the loss of precision and the double unnecessary
conversion timespec <-> timeval.
Olivier Langlois [Thu, 23 Jan 2014 00:04:45 +0000 (19:04 -0500)]
pcm: initialize pcm_dmix monotonic field
not doing so, leaves the pcm object in an inconsistent state since
'info' field is copied from the slave which is then used when
snd_pcm_hw_params_is_monotonic() is called.
For instance, when using dmix with aplay and an underrun is occuring, the following
info is returned:
Andrey Mazo [Sat, 16 Nov 2013 21:11:56 +0000 (01:11 +0400)]
pcm_file: don't touch infile on playback and output file on capture.
Commit 1d80c5b901baf7e1b7998dfa518532fbd64e4283 message describes
behaviour in case of specified infile option as
'No file writes will take place in this case'.
But this is clearly not the case as output file gets truncated while
running `arecord -Dtestin >/dev/null`, where "testin" is defined as
pcm.testin {
type file
slave.pcm null
file "/tmp/qqqq.out"
infile "/tmp/qqqq.in"
format "raw"
}
Besides that, the existing behaviour is rather counterintuitive,
requiring both output and input files to exist and making access to them
regardless of playback or capture intention.
Also, it's very confusing to get output file truncated while trying to
just capture from the device.
Current changeset introduces the following behaviour:
- output file ("file" option) is only (p)open()'ed for writing
only on playback to the device
- any data is written to the output file descriptor
(provided with "file" option) only on playback to the device
- input file ("infile" option) is only open()'ed for reading only on
capture from the device
- any data is read from the input file descriptor
(provided with the "infile" option) only on capture from the device
Signed-off-by: Andrey Mazo <mazo@telum.ru> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Andrey Mazo [Sat, 16 Nov 2013 21:11:55 +0000 (01:11 +0400)]
pcm_file: fixed memory leak.
Valgrind report for this leak was:
Command: aplay -Dfile:'/tmp/qqq',raw qqq.wav
14 bytes in 1 blocks are definitely lost in loss record 1 of 2
at 0x402BF5C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x40D7557: snd_pcm_file_hw_params (in /usr/lib/libasound.so.2.0.0)
by 0x40BA093: _snd_pcm_hw_params_internal (in /usr/lib/libasound.so.2.0.0)
by 0x40AB831: snd_pcm_hw_params (in /usr/lib/libasound.so.2.0.0)
by 0x804C523: ??? (in /usr/bin/aplay)
by 0x804E5B7: ??? (in /usr/bin/aplay)
by 0x804FC8C: ??? (in /usr/bin/aplay)
by 0x80520FB: ??? (in /usr/bin/aplay)
by 0x4184942: (below main) (libc-start.c:226)
Signed-off-by: Andrey Mazo <mazo@telum.ru> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Andrey Mazo [Sat, 16 Nov 2013 21:11:54 +0000 (01:11 +0400)]
pcm_file: fix SEGFAULT if file option is missing while infile is not.
Commit 5c5f1358123af69155267463a0b6254ad9cbecc4 requires both file and
infile options to be missing to report a failure.
In fact, only file option is mandatory and should be checked there.
Otherwise, NULL file triggers segfault in
snd_pcm_file_replace_fname() called from
snd_pcm_file_open_output_file().
infile option is optional, so don't report fatal error if it's missing.
Signed-off-by: Andrey Mazo <mazo@telum.ru> Signed-off-by: Takashi Iwai <tiwai@suse.de>