It would be greatly apreciated to add the iec958 correct device in the default USB-Audio.conf for the Xonar USB sound card :

USB-Audio.pcm.iec958_device {
...
"ASUS XONAR U5" 1
"XONAR U5" 1
...
}

It would prevent me (and maybe some other people) to freak out on why it doesn't work out of the box! :)
I know the issue is also present on the U7 but i don't have all the possible device name for it.

Thanks!

Hi, how can I compile the alsa-lib with debugging symbols enabled? Thank you!

I have a Lenovo Yoga C-930, which has a Dolby sound bar, and it seems that only one or two out of six speakers work. Is there a way I can make this work?

Here's my alsa-info: http://alsa-project.org/db/?f=87931920f5a8cbfcaa9a2490b88d8c1ed6337e9f

We want to bundle a private copy of ALSA with our application, so that the ALSA from the Linux distribution is not used at all. Yet it seems ALSA is relying on some absolute paths compiled in with no clear way to pass in a different location for ALSA at runtime.

How to do this?

Use case:
As an application developer, I want to ship my application together with all dependencies. This bundle is using musl libc, ships its own musl libc and runtime, and it is intended to also run on glibc-based systems.

Reference:
mumble-voip/mumble#3959 (comment)

I would like to know how to play simultaneous audios because I am creating a piano with '.wav' files, and I cannot emit sounds simultaneously. I have this project ready in java, but I wanted to rewrite it in C ++ with alsa-lib. Thank you!

Hello,
I wrote a simple C++ player based on alsa-lib which allows me to play wav files. I wonder if there is any convenient way to modify my code so that I can play the the wav file in the background and the main program is executing something else, say, a while loop.
Edited and Updated:
I tried to use std::thread and std::async, I was able to play the sound in the background. I looked at the header file of alsa-lib, it seems that alsa-lib natively supports playing sound asynchronously. I wonder how I could do it easily.
Thank you very much.
Best,
Lei

One build log from Ubuntu (1.1.9 but the current version has the same issue)
https://launchpadlibrarian.net/462093809/buildlog_ubuntu-focal-amd64.alsa-lib_1.1.9-0ubuntu4_BUILDING.txt.gz

The Ubuntu package has been fixed with that change
http://launchpadlibrarian.net/462101751/alsa-lib_1.2.1.2-2_1.2.1.2-2ubuntu1.diff.gz

The issue/needed changed is explained on https://docs.python.org/3/whatsnew/3.8.html

To embed Python into an application, a new --embed option must be passed to python3-config --libs --embed to get -lpython3.8 (link the application to libpython). To support both 3.8 and older, try python3-config --libs --embed first and fallback to python3-config --libs (without --embed) if the previous command fails.

The Ubuntu patch doesn't have that fallback logic though which is why I'm not proposing it with a merge request

I ran across an error in my journalctl on Ubuntu 20.04. It said to report a bug. Here is my alsa-info.sh output: http://alsa-project.org/db/?f=6b505aa5138f2a974037ab5c3a89e1605807df97
Here is the journalctl message:

pulseaudio[11933]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
pulseaudio[11933]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers.
pulseaudio[11933]: ALSA woke us up to write new data to the device, but there was actually nothing to write.

Since MIDI 2.0 only support USB and not over DIN (for now), will MIDI 2.0 need a new or updated OS class driver for the 32/64 bit universal packet interface and device descriptor for devices ? Page 16 of the USB MIDI class driver spec defines support for 1,2 or 3 bytes transfers only, How will this have to be implemented by MIDI USB device manufacturers and well as on the Linux OSes side ? How will this impact Linux ALSA ? Would the first byte of the message with b7=0 not confuse the driver of running status ?
Link universal packet format
https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange)
Link first MIDI 2.0 Ready product: Roland A-88MKII
https://www.midi.org/articles-old/roland-announces

My .config is set to $XDG_CONFIG_HOME and moving asoundrc to $XDG_CONFIG_HOME/alsa ...does not work for me.

So, today after upgrading to alsa-lib 1.2.2 I noticed the game "Shovel Knight" does no longer launch.
Any Ideas why this could be happening?
Sadly steam or the game executable won't provide any usable debug info when looking at terminal output :( .
Can I maybe use GDB to gather more info or is that useless in this case?

I have a PCIE Asus Sound Card (Asus Xonar AE) that uses USB interface:

Bus 003 Device 002: ID 0b05:180f ASUSTek Computer, Inc.

It's been working fine on earlier versions of kernel/alsa-lib but at some point the volume control stopped working (the playback still works fine):

$ alsamixer -c 1
ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.2.2-r1/work/alsa-lib-1.2.2/src/mixer/simple_none.c:1544:(simple_add1) helem (MIXER,'Master Playback Volume',0,1,0) appears twice or more
cannot load mixer controls: Invalid argument

This is on kernel 5.4.37/alsa 1.2.2. Unfortunately I cannot downgrade to the point when it was working to pinpoint the issue. I tried kernels 5.3.11 and alsa 1.1.8.
I've tried building the latest alsa-lib, and it is still showing the error.
I'm happy to try patches to alsa or kernel modules to help debug this.

$ amixer -c 1 controls
numid=7,iface=CARD,name='Clock Source 18 Validity'
numid=10,iface=CARD,name='Clock Source 19 Validity'
numid=17,iface=CARD,name='Clock Source 22 Validity'
numid=11,iface=CARD,name='IEC958 In - Output Jack'
numid=18,iface=CARD,name='Keep Interface'
numid=14,iface=CARD,name='Line - Input Jack'
numid=12,iface=CARD,name='Mic - Input Jack'
numid=8,iface=CARD,name='Speaker - Output Jack'
numid=20,iface=MIXER,name='Master Playback Volume'
numid=19,iface=MIXER,name='Master Playback Volume',device=1
numid=5,iface=MIXER,name='PCM Playback Switch'
numid=9,iface=MIXER,name='PCM Playback Switch',index=1
numid=16,iface=MIXER,name='PCM Capture Source'
numid=15,iface=MIXER,name='Line Capture Switch'
numid=13,iface=MIXER,name='Mic Capture Switch'
numid=6,iface=MIXER,name='Input Gain Pad Control'
numid=4,iface=PCM,name='Capture Channel Map'
numid=1,iface=PCM,name='Playback Channel Map'
numid=2,iface=PCM,name='Playback Channel Map',device=1
numid=3,iface=PCM,name='Playback Channel Map',device=2

amixer -c scontrols fails withe the same error as alsamixer.

A few more details:

alsa-info.txt
proc-asound.txt

I don't have the card anymore but maybe someone else have it and can provide some help cause i like the card bass/treble control and if the bug is fixed i will buy it.
The card does not output side channels at all. 5.1 works but 7.1 side channels gives no sound with speaker-test -c 8
pulseaudio also gives no sound for side channels in speaker tests.
i don't know if its the right place to report this bug but i've tried on kernel bugzilla and there is no movement there.
the kernels i've tried 1 month ago are 4.18 and 5.1.15
here is the alsainfo at that time

what i found strange is that alsamixer when i change the sound card had the side channels volume set at 0. its like by default was build intentionally without side channels support.

and yes i have that special cable with 3 jacks (sound card) to 4 jack (for speakers). i have it from an old audigy 2 zs if i remeber corectly. and the cable works since i tested 7.1 in windows without any issues.

I have a New USB headset that was added/fixed in kernel patch 5.7rc3 (https://lkml.org/lkml/2020/4/4/197). It now loads all the output options but no input options. Is there something i can do to force it?
also have this if it helps: http://alsa-project.org/db/?f=7cf962fe3df280a9a81f5cd1e82633d8cba7b02e

I was playing around with AFL tonight on one of my pet projects. And after it found few crashes, I've decided to fuzz one of open-source projects. The alsatplg tool just looked simple enough to exercise it with fuzzing tool.

I made a simple Dockerfile that runs AFL on alsatplg:

FROM ubuntu:18.04

ENV LANG C.UTF-8

RUN apt-get update && \
    apt-get install -y apt-utils && \
    apt-get install -y afl git build-essential m4 autoconf automake libtool

RUN cd /

RUN git clone https://github.com/alsa-project/alsa-lib.git
RUN cd alsa-lib && \
    	libtoolize --force --copy --automake && \
    	aclocal && \
    	autoheader && \
   		automake --foreign --copy --add-missing && \
    	autoconf && \
    	export CFLAGS="-O2 -Wall -W -Wunused-const-variable=0 -pipe -g" && \
    	export CC=afl-gcc && \
    	./configure --disable-aload && \
    	make && \
    	make install \
    && cd /

RUN apt-get install -y gettext ncurses-base libncurses5 libncurses5-dev pkg-config
RUN git clone https://github.com/alsa-project/alsa-utils.git
RUN cd alsa-utils && \
    	export CC=afl-gcc && \
        ./gitcompile && \
        make install && \
    cd /

RUN mkdir in

#RUN cp alsa-utils/speaker-test/samples/Noise.wav in
RUN echo "Hello" > in/input.txt

CMD ["afl-fuzz", "-i", "in", "-o", "out", "alsatplg", "-c", "@@", "-o", "/output"]

After around 10-15 minutes running on my core i7 laptop, it generated a sequence of bytes that leads to crash. If you want to try it by yourself just run docker build -t alsa/dev . followed by docker run alsa/dev, and wait a bit. When crash happened, the input data can be copied from the container by running docker cp <container_id>:/out ..

An example of input data that lead to SIGSEGV:
id:000000,sig:11,src:000325,op:arith8,pos:48,val:-26.txt

And stack trace based on it:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `alsatplg -c out/crashes/id:000000,sig:11,src:000325,op:arith8,pos:48,val:-26 -o'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fcb65e05ca8 in snd_config_delete () from /usr/lib/x86_64-linux-gnu/libasound.so.2
(gdb) bt
#0  0x00007fcb65e05ca8 in snd_config_delete () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#1  0x00007fcb65e06479 in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#2  0x00007fcb65e064ba in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#3  0x00007fcb65e0661c in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#4  0x00007fcb65e818c4 in snd_tplg_build_file () from /usr/lib/x86_64-linux-gnu/libasound.so.2
#5  0x00005587bce0ab6a in ?? ()
#6  0x00007fcb65a07b97 in __libc_start_main (main=0x5587bce0aa10, argc=5, argv=0x7ffcfa707628, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7ffcfa707618) at ../csu/libc-start.c:310
#7  0x00005587bce0ac4a in ?? ()
(gdb) bt full
#0  0x00007fcb65e05ca8 in snd_config_delete () from /usr/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#1  0x00007fcb65e06479 in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#2  0x00007fcb65e064ba in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#3  0x00007fcb65e0661c in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#4  0x00007fcb65e818c4 in snd_tplg_build_file () from /usr/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#5  0x00005587bce0ab6a in ?? ()
No symbol table info available.
#6  0x00007fcb65a07b97 in __libc_start_main (main=0x5587bce0aa10, argc=5, argv=0x7ffcfa707628, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7ffcfa707618) at ../csu/libc-start.c:310
        self = <optimized out>
        __self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -5452963434713232627, 94041477786656, 140724510160416, 0, 0, -2259219850243519731, -2248813385476519155}, 
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7fcb660ee733 <_dl_init+259>, 0x7fcb660d6370}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1712252723}}}
        not_first_call = <optimized out>
#7  0x00005587bce0ac4a in ?? ()
No symbol table info available.

Undecalared Variable "p" when compile alsa-lib with TPLG_DEBUG defined, the pointer 'p' in line 152 of src/topology/data.c seem not declared. see code below.

static void dump_priv_data(struct tplg_elem *elem)
{
	struct snd_soc_tplg_private *priv = elem->data;
	unsigned int i, j = 0;

	tplg_dbg(" elem size = %d, priv data size = %d\n",
		elem->size, priv->size);

	for (i = 0; i < priv->size; i++) {
		if (j++ % 8 == 0)
			tplg_dbg("\n");

		*******tplg_dbg(" 0x%x", *p++);*******
	}

	tplg_dbg("\n\n");
}

Hi,

we're using the file plugin to pipe data for use in a vu-meter application. This worked well but since updating to 1.1.4.1 the data received is incomplete (tested using sine test tones and Audacity to playback / inspect the data that went through the fifo).
When writing to a normal file all is fine.

Also tried using tee, same result.
Any hints or ideas would be great!

The fifo is created by:
#! /bin/sh

if [ ! -p "$ALSA_FIFO" ]; then
# create a fifo for alsa -> vumeter
mkfifo "$ALSA_FIFO"
chmod 666 "$ALSA_FIFO"
fi

cat <>"$ALSA_FIFO"

asound.conf:

pcm.hiface {
type hw
card 0
device 0
}

pcm.vumeter {
type rate
slave {
pcm "alsaFifo"
rate 44100
format "S16_LE"
}
}

pcm.alsaFifo {
type file
slave.pcm "null"
file "/tmp/alsa-fifo"
}

pcm.alsaFifoTee {
type empty
slave.pcm "tee:null,'/tmp/alsa-fifo',raw"
}

pcm.direct {
type route
slave.pcm "split_direct"
ttable.0.0 1
ttable.1.1 1
ttable.0.2 1
ttable.1.3 1
}

pcm.split_direct {
type multi
slaves.a.pcm "hiface"
slaves.a.channels 2
slaves.b.pcm "vumeter"
slaves.b.channels 2
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}

I've tried posting the following at alsa-users mailing list, but keep getting hit with "awaiting moderator approval" (I am registered to the list).

I'm trying to create an extplug and having trouble deciphering how the source and destination buffer reading/writing is supposed to be done in the transfer callback. My goal is to create an extplug that takes a stereo data stream, divides that into 6 or 8 output streams, and applies FIR filters to each output stream.

With the code I currently have (https://github.com/dchabot/extplug), trying to play a 1kHz tone results in a garbled, noisy mess. There is a tone in there, but it is a mess.

I started from the skeleton code here - http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_external_plugins.html. Note that the snd_pcm_extplug_create call here should be passing the "slave" variable, not "conf". That tripped me up for the better part of an hour.

I based my initial transfer callback (snd_pcm_extplug_callback_t.transfer member) on that found in the speex plugin. Initially I didn't notice that speex operated with single in/out channels, so you can imagine how that went.

Looking at another example of an extplug (https://github.com/dpapavas/alsaloudness), I noted that I should be iterating over each channel for src_areas and dst_areas. I just cannot see how this should be done properly. Is documentation for this critical step missing or simply hard to find. Seems kinda important to know how buffer operations should be done...

At this point, all I want to do is copy input channels to output channels. I'm grappling with the fact that this is more complicated than I initially thought, or perhaps more difficult than it should be.

My transfer callback currently looks like this:

/* copied from pcm-plugins/speex/pcm-speex.c */
static inline void* area_addr(const snd_pcm_channel_area_t *area, snd_pcm_uframes_t offset)
{
    unsigned int bitofs = area->first + area->step * offset;
    return (char *) area->addr + bitofs / 8;
}

static snd_pcm_sframes_t
transfer_callback(snd_pcm_extplug_t *ext, const snd_pcm_channel_area_t *dst_areas,
                             snd_pcm_uframes_t dst_offset, const snd_pcm_channel_area_t *src_areas,
                             snd_pcm_uframes_t src_offset, snd_pcm_uframes_t size)
{
    int C = ext->channels;
    short *src, *dst;
    for(int i = 0; i < C; i++) {
        src = area_addr(&src_areas[i], src_offset);
        dst = area_addr(&dst_areas[i], dst_offset);
        memcpy(dst, src, size);
    }
    return size;
}

Need a little help please.

I am using a Raspberry Pi 1 B+ with a Hifiberry DAC+ADC Pro HAT.
This HAT contains a PCM5122 Stereo DAC and an ADC.

Now to the issue: The ADC has parameters such as VINR1[SE] and VINR2[SE] + VINR1[SE]. When using alsactl store oralsactl restore, restoring will fail due to an invalid file.

ALSA lib conf.c:1887:(_snd_config_load_with_include) _toplevel_:354:30:Unexpected char

This error points to the parameter VINR1[SE], which is not surrounded by quotes. The other parameters, which also contain other special characters such as spaces, are surrounded by quotes.

An excerpt of the file is included below. This clearly illustrates which names were encapsulated between quotes.

control.28 {
                iface MIXER
                name 'ADC Right Capture Source'
                value VINR1[SE]
                comment {
                        access 'read write'
                        type ENUMERATED
                        count 1
                        item.0 'No Select'
                        item.1 VINR1[SE]
                        item.2 VINR2[SE]
                        item.3 'VINR2[SE] + VINR1[SE]'
                        item.4 VINR3[SE]
                        item.5 'VINR3[SE] + VINR1[SE]'
                        item.6 'VINR3[SE] + VINR2[SE]'
                        item.7 'VINR3[SE] + VINR2[SE] + VINR1[SE]'
                        item.8 VINR4[SE]
                        item.9 'VINR4[SE] + VINR1[SE]'
                        item.10 'VINR4[SE] + VINR2[SE]'
                        item.11 'VINR4[SE] + VINR2[SE] + VINR1[SE]'
                        item.12 'VINR4[SE] + VINR3[SE]'
                        item.13 'VINR4[SE] + VINR3[SE] + VINR1[SE]'
                        item.14 'VINR4[SE] + VINR3[SE] + VINR2[SE]'
                        item.15 'VINR4[SE] + VINR3[SE] + VINR2[SE] + VINR1[SE]'
                        item.16 '{VIN2P, VIN2M}[DIFF]'
                        item.17 '{VIN3P, VIN3M}[DIFF]'
                        item.18 '{VIN2P, VIN2M}[DIFF] + {VIN3P, VIN3M}[DIFF]'
                }
        }

Manually fixing this file by adding '' around the items which miss quotes fixes the issue, and allows restoring it.

How this leads to alsa-lib and where the issue is located

Creation of the output data and writing it to a file is handled by the save_state method in alsactl: https://github.com/alsa-project/alsa-utils/blob/master/alsactl/state.c#L1539
This code in turn calls snd_config_save in the alsa-lib project:

Proposed solution
The characters [ and ] should be a reason to put text between quotes.
These characters should be added to the switch statement in print_string here:

Regards,
Bert

Multiple Unity3D games crash on launch if you try to launch them while pulseaudio is not running. For games using the ScreenSelector.so plugin, the crash happen after the screen resolution selection.

It seems to only happen on systems using Mesa + amdpgu.

The crash happens with alsa-lib v1.2.2, but does not happen with alsa-lib 1.1.8. This allowed me to run a regression test and find the faulty commit:

commit 5ee5ef31b5ff3fb7c904054cb9cac7478a727f7c
Author: Jaroslav Kysela <[email protected]>
Date:   Sun Dec 1 14:26:40 2019 +0100

    namehint: correct the @args check
    
    BugLink: https://github.com/alsa-project/alsa-plugins/issues/3
    Signed-off-by: Jaroslav Kysela <[email protected]>

diff --git a/src/control/namehint.c b/src/control/namehint.c
index 808df6b5..4927ef97 100644
--- a/src/control/namehint.c
+++ b/src/control/namehint.c
@@ -348,6 +348,12 @@ static int try_config(snd_config_t *config,
                goto __cleanup;
        if (snd_config_search(res, "@args", &cfg) >= 0) {
                snd_config_for_each(i, next, cfg) {
+                       /* skip the argument list */
+                       snd_config_get_id(snd_config_iterator_entry(i), &str);
+                       while (*str && *str >= '0' && *str <= '9') str++;
+                       if (*str == '\0')
+                               continue;
+                       /* the argument definition must have the default */
                        if (snd_config_search(snd_config_iterator_entry(i),
                                              "default", NULL) < 0) {
                                err = -EINVAL;

From what I understand, this commit has been used to fix the following issue: alsa-project/alsa-plugins#3

The following patch applies cleanly on tag v1.2.2 and current master, and fixes this crash:

From a236046a14b438c96889a46cf8baf38b19b7b45e Mon Sep 17 00:00:00 2001
From: vv221 <[email protected]>
Date: Mon, 16 Mar 2020 16:05:24 +0100
Subject: [PATCH] Revert 5ee5ef31b5ff3fb7c904054cb9cac7478a727f7c "namehint:
 correct the @args check"

This fixes a regression trigerring a crash with Unity3D games if
pulseaudio is not running.

Research about this crash can be found on ./play.it issues tracker:
https://forge.dotslashplay.it/play.it/games/issues/355
---
 src/control/namehint.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/src/control/namehint.c b/src/control/namehint.c
index 60c48ae3..808df6b5 100644
--- a/src/control/namehint.c
+++ b/src/control/namehint.c
@@ -348,13 +348,6 @@ static int try_config(snd_config_t *config,
                goto __cleanup;
        if (snd_config_search(res, "@args", &cfg) >= 0) {
                snd_config_for_each(i, next, cfg) {
-                       /* skip the argument list */
-                       if (snd_config_get_id(snd_config_iterator_entry(i), &str) < 0)
-                               continue;
-                       while (*str && *str >= '0' && *str <= '9') str++;
-                       if (*str == '\0')
-                               continue;
-                       /* the argument definition must have the default */
                        if (snd_config_search(snd_config_iterator_entry(i),
                                              "default", NULL) < 0) {
                                err = -EINVAL;
-- 
2.25.1

It is probably not ideal, as I guess it would restore the regression it was supposed to fix.

The original research about this regression can be found on ./play.it issues tracker: Unity3D + amgdpu (Mesa) — Crash on launch if pulseaudio is not running

The following documentation is incomplete. It doesn't explain what "avail min" or "avail max" means. It's like asking someone you just met "what is your maximum age?". We need more context for the phrase "maximum number of frames available" to be meaningful. Is it maximum allowed before frames start getting dropped? Is it the maximum that we've seen over the course of operating the device?

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___s_w___params.html

snd_pcm_sw_params_get_avail_min()

    Get avail min from a software configuration container.

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___status.html#gac58d13e4d03c9420c57428ddffd94964

snd_pcm_status_get_avail_max()

    Get maximum number of frames available from a PCM status container after last
    snd_pcm_status call.

    Returns
        Maximum number of frames ready to be read/written

The following is less important, but it still should be fixed. We need to explain what a "software configuration container" is. The phrase is used all over the place; it only needs to be defined once:

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga7e082d9ea701709270b0674a0be23b09

snd_pcm_sw_params_t

typedef struct _snd_pcm_sw_params snd_pcm_sw_params_t

PCM software configuration container

Hi all,

I am currently working on an open source project on GitHub AES67 Linux daemon with WebUI.
This project uses the Merging Technologies ALSA RAVENNA/AES67 Linux Driver.
This ALSA driver does support the mmap access using indirect PCM data transfer.

The driver is working properly when used directly but not when it's used via the dshare plugin.
See issue No sound using dshare in asound.conf in the AES67 Linux daemon project.

For all my tests I used the Linux Kernel 5.3.0-51 and the alsa-lib v1.1.9 but I get same results with most recent kernel and with the alsa-lib on the master branch.
My .asoundrc configuration is the following:

pcm.aes67 {
        type hw
        card 1
        device 0
        #sync_ptr_ioctl true
}

pcm_slave.nforce {
    pcm "aes67"
    channels 2
    rate 48000
    buffer_size 24576  
    period_size 48
    format S24_3LE
    periods 0
    period_time 1000
}

pcm.ch12 {
   type dshare
   ipc_key 47110815
   slave nforce
   bindings.0 0
   bindings.1 1
   #slowptr true
}

Basically when I playback a sample PCM audio using the ALSA RAVENNA/AES67 HW device directly via mmap I get a proper playout.
Ex: aplay -D hw:1 sample.raw -M
But if I do the same using the dshare plugin I do always get no audio (silence):
Ex: aplay -D ch12 sample.raw -M

After a number of tests trying to compare the behavior of the alsa-lib when using the ALSA driver directly (aplay -D hw:1) and when using the plugin (aplay -D ch12) I realized that in the second case the SNDRV_PCM_IOCTL_SYNC_PTR ioctl is never triggered in the audio loop by the alsa-lib . (I could easily capture this by using strace).
I would expect the snd_pcm_dshare_mmap_commit() function of alsa-lib to invoke the above ioctl but this is not happening.
The result is that in the ALSA driver the ack() callback is not called to indicate that the appl_ptr is updated and this causes the problem we have.

In the Linux kernel when the ioctl SNDRV_PCM_IOCTL_SYNC_PTR is called the following functions are called:
snd_pcm_sync_ptr() -> pcm_lib_apply_appl_ptr() -> substream->ops->ack()
but as stated above this is happening only if the ALSA driver is used directly (aplay -D hw:1) and not when it's used via the plugin (aplay -D ch12).

I could fix the issue applying the following temporary fix to the alsa-lib:

diff --git a/src/pcm/pcm_dshare.c b/src/pcm/pcm_dshare.c
index f135b5df..1f103414 100644
--- a/src/pcm/pcm_dshare.c
+++ b/src/pcm/pcm_dshare.c
@@ -562,6 +562,7 @@ static snd_pcm_sframes_t snd_pcm_dshare_mmap_commit(snd_pcm_t *pcm,
                /* clear timer queue to avoid a bogus return from poll */
                if (snd_pcm_mmap_playback_avail(pcm) < pcm->avail_min)
                        snd_pcm_direct_clear_timer_queue(dshare);
+               dshare->spcm->fast_ops->mmap_commit(dshare->spcm, offset, size);
        }
        return size;
 }

The fix basically triggers the call to the snd_pcm_hw_mmap_commit() function of the slave pcm of the dshare plugin. This function invokes the issue_applptr() and then the sync_ptr1() that finally calls the SNDRV_PCM_IOCTL_SYNC_PTR ioctl to update the appl_ptr in the kernel.

After applying this fix I can properly hear the audio.

I am available to provide any additional information and to do additional tests.
Since I don't have much experience with the alsa-lib it can be that the problem is related to some misconfiguration but at present I managed to solve the issue only by applying the above fix.

Thanks in advance for your help.

I had been intending to modify the example program test/latency.c in the alsa-lib distribution to build a filter.

However, I found the original program itself was unable to produce a good transfer of audio.

I am using it like

./latency -C plughw:3 -P hw:0,7 -r 44100 -m 256 -M 512 -c 2 -s 3000

but I also tried higher numbers (2048 and 4096) for -m and -M and this didn't help.

This command should theoretically work to transfer audio samples between the capture device, hw:3 which is a USB audio card with 3.5mm input, and the playback device hw:0,7 which is an HDMI monitor with builtin speakers. The second device has no volume control in alsamixer.

Most of the times when I run the above command, there is a scratchy sound which can be heard here

mpv http://ix.io/2mPY

In the recording, whenever the music stops and starts again, it's because I killed the 'latency' program and restarted it. You can hear that there are different levels of distortion from one invocation to the next. The signal is coming from a digital audio player which is plugged into the USB sound card via analog 3.5mm. Nothing else changes about the setup, I am just stopping and starting "./latency".

The same level of scratchiness usually persists throughout the running of the program, however, each time the program is restarted a new level of scratchiness is chosen seemingly at random. It's almost like every time the program is started, a threshold is chosen uniformly at random, such that whenever the audio signal exceeds this threshold then it gets clipped. The other circumstances would seem to rule out buffer underflow or crystal drift, and there is no warning of dropped samples. I made some experiments, and even the effect of dropping every 10th sample sounds less distorted than this. But if it is from crystal drift, it should be more like every 1/1000th sample getting dropped. The sound that I am hearing is more like the result of zeroing or thresholding all the samples which exceed a certain amplitude, and a significant number of samples must be affected to make it sound this bad.

I do not notice this problem with "ecasound -i .. -o .." or with Pulseaudio's "module-loopback", which are both able to produce clear audio. As I uderstand it, ecasound does not do resampling to account for crystal drift. Pulseaudio's module-loopback does do adaptive resampling.

I'm including the command that I use, and the output. I don't know what some of those words mean - tstamp_mode, start_threshold, silence_threshold, period_event. Anyway, please let me know if it is possible to make this program behave more like Pulseaudio or Ecasound. I'll be happy to assist with reproduction issues and so on.

$ ./latency -P hw:0,7 -C plughw:3 -r 44100 -m 4096 -M 16384 -c 2 -s 3000
!!!Scheduler set to Round Robin with priority 99 FAILED!!!
Playback device is hw:0,7
Capture device is plughw:3
Parameters are 44100Hz, S16_LE, 2 channels, non-blocking mode
Poll mode: no
Loop limit is 132300000 frames, minimum latency = 4096, maximum latency = 16384
Hardware PCM card 0 'HD-Audio Generic' device 7 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 2048
  period_time  : 46439
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 2048
  period_event : 0
  start_threshold  : 2147483647
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0
Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 2048
  period_time  : 46439
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 2048
  period_event : 0
  start_threshold  : 2147483647
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Hardware PCM card 3 'USB Audio Device' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 2048
  period_time  : 46439
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 2048
  period_event : 0
  start_threshold  : 2147483647
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0
Trying latency 4096 frames, 92879.819us, 92.879819ms (10.7666Hz)

The Linux distribution is Arch, the kernel is 5.6.10-arch1-1, x86_64 GNU/Linux. Thank you.

arecord -L will show pcms which are not capture pcms (for instance front speakers, surroundX).

Don't know if it is fix-able. Wait for topology/ucm port of classic drivers?

Axfer calls polling system call(i.e. poll(2), epoll(7), select(7)) without explicit timeout when running for IRQ-based scheduling model. In a case that driver achieves to control sound hardware for periodical hardware IRQ, the call can return due to any event queued by the driver in hardware IRQ context. However, in a case that driver fails to control it, the call cannot return.

Especially, this situation easily occurs when developers work to support hardware newly. It's better to care for the situation.

How to reproduce:

1. prepare sound hardware which driver fail to control for periodical hardware IRQ.
2. execute axfer for the driver/hardware with options to:

• use IRQ-based scheduling model: --sched-model=irq
• use polling system call: without --test-nowait

3. the running process blocks as a call of polling system call (defaultly poll(2) by snd_pcm_wait())

In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes that can be read using a snd_rawmidi_read. (port is opened for input only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer?
snd_rawmidi_status_alloca (&status);
snd_rawmidi_status(client, status);
snd_rawmidi_status_get_avail(status);

When build with LTO test suite is failing

[tkloczko@barrel alsa-lib-1.2.3]$ make check
Making check in doc
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/doc'
Making check in pictures
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/doc/pictures'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/doc/pictures'
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/doc'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/doc'
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/doc'
Making check in include
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include'
Making check in sound
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include/sound'
Making check in uapi
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include/sound/uapi'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include/sound/uapi'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include/sound'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include/sound'
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include/sound'
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include'
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include'
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/include'
Making check in src
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src'
Making check in control
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/control'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/control'
Making check in mixer
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/mixer'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/mixer'
Making check in pcm
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/pcm'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/pcm'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/pcm'
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/pcm'
Making check in timer
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/timer'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/timer'
Making check in rawmidi
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/rawmidi'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/rawmidi'
Making check in hwdep
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/hwdep'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/hwdep'
Making check in seq
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/seq'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/seq'
Making check in ucm
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/ucm'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/ucm'
Making check in conf
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf'
Making check in cards
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf/cards'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf/cards'
Making check in pcm
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf/pcm'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf/pcm'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf'
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/conf'
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src'
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src'
Making check in src/topology
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/topology'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/src/topology'
Making check in modules
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules'
Making check in mixer
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules/mixer'
Making check in simple
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules/mixer/simple'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules/mixer/simple'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules/mixer'
make[3]: Nothing to be done for 'check-am'.
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules/mixer'
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules/mixer'
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules'
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/modules'
Making check in aserver
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/aserver'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/aserver'
Making check in test
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/test'
Making check in .
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/test'
make  control pcm pcm_min latency seq playmidi1 timer rawmidi midiloop oldapi queue_timer namehint client_event_filter chmap audio_time user-ctl-element-set pcm-multi-thread
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/test'
make[3]: 'control' is up to date.
make[3]: 'pcm' is up to date.
make[3]: 'pcm_min' is up to date.
make[3]: 'latency' is up to date.
make[3]: 'seq' is up to date.
make[3]: 'playmidi1' is up to date.
make[3]: 'timer' is up to date.
make[3]: 'rawmidi' is up to date.
make[3]: 'midiloop' is up to date.
/bin/sh ../libtool  --tag=CC   --mode=link gcc -Wall -pipe -g -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -o oldapi oldapi.o ../src/libasound.la
libtool: link: gcc -Wall -pipe -g -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -o .libs/oldapi oldapi.o  ../src/.libs/libasound.so -lm -ldl -lpthread -lrt
/usr/bin/ld: oldapi.lto.o: in function `main':
/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/test/oldapi.c:39: undefined reference to `snd_pcm_hw_params_get_access@ALSA_0.9'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:529: oldapi] Error 1
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/test'
make[2]: *** [Makefile:796: check-am] Error 2
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/test'
make[1]: *** [Makefile:645: check-recursive] Error 1
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.2.3/test'

In a non-blocking dmix-ed plugin pipeline (see below), playing audio from a 44100Hz source to a running 48000Hz hardware pcm, will go into an -EAGAIN infinite loop in snd_pcm_drain().
I did a bit of tracing and it seems snd_pcm_drain() will always return -EAGAIN because in pcm_dmix.c:snd_pcm_dmix_sync_ptr0, avail is never >= pcm->stop_threshold

While developing a client using the raw MIDI interface, bumped into an issue that
went away after rebooting Ubuntu 19.10 - 64 bit. Using a MIDISPORT 4x4 one of the 4 ports could not be opened. The client (written in C) call hang and the client thus went unresponsive. No timeout, no error, no nothing. CTRL-BREAK the client and retrying many times gave the exact same result, no other apps were using the port. The other 3 ports on the interface and any other MIDI USB device connected could be opened and used without any problem.

When opening the port with amidi, an error was reported, it seems amidi did not gracefully exit as well.

amidi -receive -p hw:3,0,1
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC3D0 failed: Device or resource busy
cannot open port "hw:3,0,1": Device or resource busy

Looking at the rawmidi_hw.c code there is a GOTO and SYSERR statement. Not sure if those caused this .

if (fd < 0) {
snd_ctl_close(ctl);
SYSERR("open %s failed", filename);
return -errno;
.
After reboot the problem went away. The problem could have been caused while fixing some by coding issue. Maybe someone with more understanding of the code can spot an issue in the code. While many applications use the raw MIDI interface. believe Bitwig and most others use the sequencer API to open ports.

Just wanted to log this just in case anyone else experiences this

Tried everything I can think of to record at 384. How do I do it?

Thanks!

I hope this is the right place to report this. This occurred in relation to a crash.
http://alsa-project.org/db/?f=52e8505d884682fc06adac4ab8ce92a4ca3e0870

E: [alsa-sink-ALC887-VD Analog] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 177312 bytes (923 ms).
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: snd_pcm_dump():
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Soft volume PCM
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Control: PCM Playback Volume
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: min_dB: -51
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: max_dB: 0
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: resolution: 256
E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Its setup is:
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   stream       : PLAYBACK
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   access       : MMAP_INTERLEAVED
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   format       : S16_LE
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   subformat    : STD
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   channels     : 2
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   rate         : 48000
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   exact rate   : 48000 (48000/1)
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   msbits       : 16
E: [alsa-sink-ALC887-VD Analog] alsa-util.c:   buffer_size  : 4800

After updating alsa-lib from 1.2.2 to 1.2.3, alsa-ucm-conf from 1.2.2 to 1.2.3, and alsa-topology-conf from 1.1.1 to 1.2.3, the maximum volume of the headphone out on my Dell WD19TB dock became much lower, to the point where it can’t be set loud enough for normal listening.

The output devices reported in Gnome Settings are also different.

1.2.2:

1.2.3:

The dock does indeed have a headphone out on the front, and a line out on the back, so the line out being detected now is good. The volume range of the line out on 1.2.3 is similar to that of the headphone out on 1.2.2, but the volume range of the headphone out on 1.2.3 is much lower.

The card itself as reported by pactl list-cards on 1.2.2:

    index: 0
	name: <alsa_card.usb-Generic_USB_Audio_200901010001-00>
	driver: <module-alsa-card.c>
	owner module: 6
	properties:
		alsa.card = "1"
		alsa.card_name = "WD19 Dock"
		alsa.long_card_name = "Dell-WD15-Dock"
		alsa.driver_name = "snd_usb_audio"
		device.bus_path = "pci-0000:0b:00.0-usb-0:2.3.4:1.0"
		sysfs.path = "/devices/pci0000:00/0000:00:1d.6/0000:06:00.0/0000:07:01.0/0000:09:00.0/0000:0a:02.0/0000:0b:00.0/usb3/3-2/3-2.3/3-2.3.4/3-2.3.4:1.0/sound/card1"
		udev.id = "usb-Generic_USB_Audio_200901010001-00"
		device.bus = "usb"
		device.vendor.id = "0bda"
		device.vendor.name = "Realtek Semiconductor Corp."
		device.product.id = "402e"
		device.product.name = "USB Audio"
		device.serial = "Generic_USB_Audio_200901010001"
		device.string = "1"
		device.description = "USB Audio"
		module-udev-detect.discovered = "1"
		device.icon_name = "audio-card-usb"
	profiles:
		input:analog-stereo: Analog Stereo Input (priority 65, available: unknown)
		output:analog-stereo: Analog Stereo Output (priority 6500, available: unknown)
		output:analog-stereo+input:analog-stereo: Analog Stereo Duplex (priority 6565, available: unknown)
		off: Off (priority 0, available: unknown)
	active profile: <output:analog-stereo+input:analog-stereo>
	sinks:
		alsa_output.usb-Generic_USB_Audio_200901010001-00.analog-stereo/#0: USB Audio Analog Stereo
	sources:
		alsa_output.usb-Generic_USB_Audio_200901010001-00.analog-stereo.monitor/#0: Monitor of USB Audio Analog Stereo
		alsa_input.usb-Generic_USB_Audio_200901010001-00.analog-stereo/#1: USB Audio Analog Stereo
	ports:
		analog-input-mic: Microphone (priority 8700, latency offset 0 usec, available: unknown)
			properties:
				device.icon_name = "audio-input-microphone"
		analog-output-headphones: Headphones (priority 9900, latency offset 0 usec, available: unknown)
			properties:
				device.icon_name = "audio-headphones"

And as reported on 1.2.3:

    index: 0
	name: <alsa_card.usb-Generic_USB_Audio_200901010001-00>
	driver: <module-alsa-card.c>
	owner module: 6
	properties:
		alsa.card = "1"
		alsa.card_name = "WD19 Dock"
		alsa.long_card_name = "Dell-WD15-Dock"
		alsa.driver_name = "snd_usb_audio"
		device.bus_path = "pci-0000:0b:00.0-usb-0:2.3.4:1.0"
		sysfs.path = "/devices/pci0000:00/0000:00:1d.6/0000:06:00.0/0000:07:01.0/0000:09:00.0/0000:0a:02.0/0000:0b:00.0/usb3/3-2/3-2.3/3-2.3.4/3-2.3.4:1.0/sound/card1"
		udev.id = "usb-Generic_USB_Audio_200901010001-00"
		device.bus = "usb"
		device.vendor.id = "0bda"
		device.vendor.name = "Realtek Semiconductor Corp."
		device.product.id = "402e"
		device.product.name = "USB Audio"
		device.serial = "Generic_USB_Audio_200901010001"
		device.string = "1"
		device.description = "USB Audio"
		module-udev-detect.discovered = "1"
		device.icon_name = "audio-card-usb"
	profiles:
		HiFi: Default (priority 8000, available: unknown)
		off: Off (priority 0, available: unknown)
	active profile: <HiFi>
	sinks:
		alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock_1__sink/#0: USB Audio Line Out
		alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__sink/#1: USB Audio Headphones
	sources:
		alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock_1__sink.monitor/#0: Monitor of USB Audio Line Out
		alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__sink.monitor/#1: Monitor of USB Audio Headphones
		alsa_input.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__source/#2: USB Audio Microphone
	ports:
		[Out] Line: Line Out (priority 200, latency offset 0 usec, available: unknown)
			properties:
				
		[Out] Headphones: Headphones (priority 100, latency offset 0 usec, available: unknown)
			properties:
				
		[In] Mic: Microphone (priority 100, latency offset 0 usec, available: unknown)
			properties:

See subject. There is a way to run user code in a signal handler with snd_async_add_pcm_handler(). But that seems extremely questionable, is for sure not supported everywhere, and is probably full of subtle synchronization bugs. There is snd_pcm_poll_descriptors() and related, but that seems to signal only whether at least 1 period is available, nothing else. Judging from the docs.

That seems like a rather big missing thing - I probably overlooked something. Otherwise this is a feature request for an asynchronous notification on period boundaries/underruns/device disconnection, that does not run in a UNIX signal handler. Maybe something relatively similar to that poll() mechanism.

According to https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
period_size in dmix is bytes per period.

According to aplay --dump-hw-params -D dmix ...
period_size is frames per period.

Which one is right?

When using the ALSA File plugin you can tell it to pipe playback data to either a file or a program/shell command.

Output filename (or shell command the stream will be piped to if STR starts with the pipe char).

Piping to a shell command (as shown below) causes a deadlock where alsa waits for the shell command to return at the same time that the shell command is waiting for alsa to write to its STDIN.

From the source code, it appears that popen is being used to initialize/open the output file specified in configuration:

static int snd_pcm_file_open_output_file(snd_pcm_file_t *file)
{
    int err, fd;

    /* fname can contain keys, generating final_fname */
    err = snd_pcm_file_replace_fname(file, &(file->final_fname));
    if (err < 0)
        return err;
    /*printf("DEBUG - original fname: %s, final fname: %s\n",
      file->fname, file->final_fname);*/

    if (file->final_fname[0] == '|') {
        /* pipe mode */
        FILE *pipe;
        /* clearing */
        pipe = popen(file->final_fname + 1, "w");
        if (!pipe) {
            SYSERR("running %s for writing failed",
                    file->final_fname);
            return -errno;
        }
        fd = dup(fileno(pipe));
        err = -errno;
        pclose(pipe);
        if (fd < 0) {
            SYSERR("unable to dup pipe file handle for command %s",
                    file->final_fname);
            return err;  

Although I can confirm the file I pass in my ALSA configuration gets started fine, it never receives anything on its stdin like ALSA's (and popen's) documentation states it should:

If mode is w, when the child process is started its file descriptor STDIN_FILENO shall be the readable end of the pipe, and the file descriptor fileno(stream) in the calling process, where stream is the stream pointer returned by popen(), shall be the writable end of the pipe.

My /etc/asound.conf:

pcm.!default {
    type plug
    slave.pcm "duplicator
}

pcm.default {
    type plug
    slave.pcm "duplicator"
}

pcm.dmixer {
    type dmix
    ipc_key 1024
    ipc_key_add_uid false
    ipc_perm 0666
    slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        buffer_size 8192
        rate 44100
    }
}    

pcm.duplicator {
    type plug
    slave.pcm {
        type multi
        slave {
            a { pcm "dmixer" channels 2 }
            b { pcm "fileout" channels 2 }
        }
        bindings [
            { slave a channel 0 }
            { slave a channel 1 }
            { slave b channel 0 }
            { slave b channel 1 }
        ]
    }
    ttable [
        [ 1 0 1 0 ]
        [ 0 1 0 1 ]
    ]
}

pcm.fileout {
    type file
    slave.pcm "null"
    file "|safe_fifo_alt"
    format raw
    perm 0666
}  

safe_fifo_alt:

#!/usr/bin/python3
import os, sys

BUFFER_SIZE = 16384

path = "/tmp/audio"
if not os.path.exists(path):
    os.mkfifo(path)
    
_fifo_in = os.open(path, os.O_RDONLY | os.O_NONBLOCK)
_fifo_out = os.open(path, os.WR_ONLY | os.O_NONBLOCK)

for chunk in iter(lambda: sys.stdin.buffer.read(BUFFER_SIZE), b''):
    os.write(_fifo_out, chunk)
    
os.close(_fifo_in)
os.close(_fifo_out)  

I based safe_fifo_alt on safe_fifo from cli-visualizer. They both hang indefinitely on their STDIN read because alsa is hanging on its pclose().

I've tested an alternative method to simulate the popen and pipe into their STDIN to make sure it worked, specifically:

head -c 500 /dev/urandom | sh -c safe_fifo_alt  

It appears this was changed in revision 22ade9b, where the dup() and pclose() calls were added and introduced the deadlock.

Plugging in a usb microphone causes pulse audio to crash with alsa-lib 1.2.3.

make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/alsa-lib-1.1.8/src'
/bin/sh ../libtool  --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto -version-info 2:0:0 -Wl,--version-script=Versions  -Wl,--no-undefined -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto -fuse-linker-plugin -o libasound.la -rpath /usr/lib64 conf.lo confmisc.lo input.lo output.lo async.lo error.lo dlmisc.lo socket.lo shmarea.lo userfile.lo names.lo control/libcontrol.la mixer/libmixer.la pcm/libpcm.la timer/libtimer.la rawmidi/librawmidi.la hwdep/libhwdep.la seq/libseq.la ucm/libucm.la topology/libtopology.la  -lm -ldl -lpthread -lrt 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/conf.o .libs/confmisc.o .libs/input.o .libs/output.o .libs/async.o .libs/error.o .libs/dlmisc.o .libs/socket.o .libs/shmarea.o .libs/userfile.o .libs/names.o  -Wl,--whole-archive control/.libs/libcontrol.a mixer/.libs/libmixer.a pcm/.libs/libpcm.a timer/.libs/libtimer.a rawmidi/.libs/librawmidi.a hwdep/.libs/libhwdep.a seq/.libs/libseq.a ucm/.libs/libucm.a topology/.libs/libtopology.a -Wl,--no-whole-archive -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -g -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -flto -Wl,--version-script=Versions -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -flto -fuse-linker-plugin    -lm -ldl -lpthread -lrt -Wl,-soname -Wl,libasound.so.2 -o .libs/libasound.so.2.0.0
/tmp/ccROQp1D.s: Assembler messages:
/tmp/ccROQp1D.s: Error: invalid attempt to declare external version name as default in symbol `snd_dlopen@@ALSA_1.1.6'
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

The games segfault right at the start. The actual crash happens with a backtrace that does not contain any libalsa functions.
Examples: I tried »Ara Fell« and »The Coma 2 Vicious Sisters« (sourced from gog.com), but there are probably more.

My gdb-fu is unfortunately not good enough to find out the exact problem. It would be very cool if this could be fixed on the libalsa-side, as many of those games will probably never see an update.

Does this filter out receiving 0xFE incoming and outgoing messages when enabled ? Still see incoming active sensing messages after using this.

Googling "alsa report issue" or "alsa report bug" takes me to the following page:

https://www.alsa-project.org/wiki/Bug_Tracking

This page should have a link to https://github.com/alsa-project/alsa-lib/issues/

hi,
the example pcm_min.c located in alsa-lib/test/ is missing a "snd_pcm_drain(handle);" before the handle is closed.

while the example works as is, the lack of calling ...drain before ...close means that the end of the sample being played is truncated. when expanding the example to play actual content (rather than random noise) this becomes an issue.

i took this example and used it as the basis of my own routine that played a sine wave tone (with the volume feathered at the start and end). many hours were spent trying to work around this problem of truncated output, before one of the developers pointed out that i needed to drain before closing. as i am a beginner with ALSA and working from scant information, i didn't know that snd_pcm_drain() even existed.

cheers,
rob :-)

Hello again!

I upgraded Alsa lib to 1.1.7 and tested ok. A small error as below when running in Jupyter Notebook, Python 3.6::

`#inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE, alsaaudio.PCM_NONBLOCK)

UltraMic384K 16bit r0, USB Audio

inp = alsaaudio.PCM(type = alsaaudio.PCM_CAPTURE, mode=alsaaudio.PCM_NORMAL, device='UltraMic384K 16bit r0')
# class alsaaudio.PCM(type=PCM_PLAYBACK, mode=PCM_NORMAL, device='default', cardindex=-1)`

TypeError Traceback (most recent call last)
in
16 modelName="randomforestPaddyFalse"
17 modelType="randomforest"
---> 18 recordAnalyzeAudio(10, outputWavFile, 2.0, modelName, modelType)

in recordAnalyzeAudio(duration, outputWavFile, midTermBufferSizeSec, modelName, modelType)
87 # UltraMic384K 16bit r0, USB Audio
88
---> 89 inp = alsaaudio.PCM(type = alsaaudio.PCM_CAPTURE, mode=alsaaudio.PCM_NORMAL, device='UltraMic384K 16bit r0')
90 # class alsaaudio.PCM(type=PCM_PLAYBACK, mode=PCM_NORMAL, device='default', cardindex=-1)
91 inp.setchannels(2)

TypeError: 'device' is an invalid keyword argument for this function

Thanks!

In the latest UCM for sof-hda-dsp, it has supported Syntax 3 and it uses $var for hdmi. In sof-hda-dsp/Hdmi.conf, It defines "HdmiNum 1", and later it will redefine "HdmiNum 2", then "HdmiNum 3". It will try to Include.hdmi1.File "/codecs/hda/hdmi.conf" to use these definitions. But actually, only "HdmiNum 3" will be used for HDMI1, HDMI2 and HDMI3. The old value of "1" and "2" will be overridden when parsing HDMI1 and HDMI2. This is the bug of alsa-lib initialization sequence issue.

HDA-Intel/Hdmi.conf should have the same issue.

I upgraded the newest alsa,but I found my sound card can't found,and sound output is unable to use.
My Device:DELL G3 3500
Sound Card:Realtek ALC3254
Terminal Output:
[dale-g33500 dale]# lspci | grep -i audio
00:1f.3 Multimedia audio controller: Intel Corporation Device 06c8
01:00.1 Audio device: NVIDIA Corporation Device 10fa (rev a1)
[dale-g33500 dale]# cat /proc/asound/cards
0 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0x83000000 irq 17
[dale-g33500 dale]# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version k5.7.9-1-MANJARO.
[dale-g33500 dale]# head -5 /proc/asound/card0/codec#0
Codec: Nvidia GPU 94 HDMI/DP
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x10de0094
Subsystem Id: 0x102809e1
[dale-g33500 dale]# pacman -Q alsa-lib
alsa-lib 1.2.3.2-1
The Realtek Sound Card is disappeared!

Sound is about 30% lower with alsa 1.2.3 than with alsa 1.2.2 using the same volume setting. Backing down to 1.2.2 to restore order as the natives are getting stabby.

Can you make sample of alsa processor that is have input and output in the code?

I know only syntax of C and I want to program DSP for linux output sound.

I'm sorry if this isn't the correct project for this. I don't know if this problem is relevant to the Alsa project or the Linux kernel directly and I don't know how to find that out.

Personal background

Programmer, experienced. First used Linux with Red Hat Linux 6 about 20 years ago. Mostly using Linux on the server side of things since. I'm not afraid to try things so have at it.

Problem

PCM audio to device heavily distorted and extremely low volume. Happens with all applications. Works flawlessly with Windows. Bypassing PulseAudio using aplay or speaker-test does not help. Interestingly, playing a raw sine wave with speaker-test works fine! Therefore it's only PCM based output causing an issue. Even using something like VLC which has it's own codecs and outputs directly to the sound buffer exhibits this issue, so it's not a system codec issue. For example, this produces a perfectly fine sounding sine wave

speaker-test -l 3 -t sine -c 2

And this produces nothing

speaker-test -l 3 -t wav -c 2

If I play something on Spotify or Youtube and max out the volume I can barely hear some heavily distorted, clipped noise vaguely sounding like it should.

I only have powered headphones for testing, no powered external speakers.

Relevant details

Latest KDE neon, which is Ubuntu 18.04 base with the GUI switched from Gnome to KDE Plasma.

Hardware is an Asus z170 motherboard, integrated Realtek/Intel audio. Using the rear green line out jack. I think there are headphone jack headers on the board as well, they are unused.

lspci output

00:1f.3 Audio device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31)
01:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1)

kernel messages regarding snd

snd_hda_intel 0000:01:00.1: Disabling MSI
snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client
snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
snd_hda_codec_realtek hdaudioC0D0:    dig-out=0x11/0x1e
snd_hda_codec_realtek hdaudioC0D0:    inputs:
snd_hda_codec_realtek hdaudioC0D0:      Front Mic=0x19
snd_hda_codec_realtek hdaudioC0D0:      Rear Mic=0x18
snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a

Output of alsa-info dumping everything it knows about

https://pastebin.com/wCif6Qzv

I'm stuck and don't know where to go from here. Since utilities like aplay and sound-test bypass PulseAudio I think it's a problem with Alsa or the device driver for this card. That's as far as I can discover on my own.

Things I have tried

• Using alsamixer, confirming all volume sliders at max, none are muted. Maxing out all sliders is when I can barely make out garbled output through powered headphones.
• Using Ubuntu Mainline Kernel Installer, signing it properly, and upgrading the kernel from 5.3.0 to 5.7.9
• Using hdajackretask and overriding jack plugin detection
• Modifying PulseAudio config to not resample and force sampling to 44.1khz
• Playing around with pavucontrol and kde equivalents, disabling the unused nvidia output and trying different jack configurations

I also found some modprobe settings for Realtek devices, however usually that information was usually about 6-8 years old and didn't look relevant.

Hotplug support is mandatory in any modern system. But in ALSA there is no way to be notified by audio device changes.

I'm aware that as a hack, one could listen to udev notifications. But this is not appropriate, because:

• udev is a different API, which makes this is inelegant and messy
• it requires a dependency on udev, which may not be a workable solution even if the host OS is Linux
• there may be devices that do not have anything to do with udev (for example network audio interfaces implemented in userspace)
• changes in udev may not be reflected in ALSA at the same time (creating the need to avoid race conditions with timeouts or whatever)
• it's ALSA's responsibility to provide this; I don't know any OS where you have to go to a completely different API for this

Hi. I am using HP OMEN dc0019ur laptop with linux 5.7-xanmod kernel and KDE neon (Ubuntu-based) system.
Laptop has combined 3.5mm jack and a seperate stereo microphone jack.
Tried various quirks by creating /etc/modprobe.d/mute.conf file and adding line "options snd-hda-intel model=XX", where XX is the name of the quirk from documentation here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sound/hd-audio/models.rst

With no modprobe changes:
mute led does not work, headphones work, but microphone is not detected, and if i plug anything into microphone jack, it switches to microphone in combined jack.

With hp-line1-mic1 quirk: mute led works fine, headphones are detected, except microphone, though it works anyway. Seperate microphone jack does not work at all.

With headset-mic quirk:
mute led does not work, headphones jack works, microphone (from headphones jack) is not detected when present but works when switched to anyway
Microphone jack works perfectly (detects a plugged in mic, works in stereo).

--- alsa-info.sh logs ---
no quirks: http://alsa-project.org/db/?f=a73a83ba0610e3fd88310999b197fdde4372249a
hp-line1-mic1: http://alsa-project.org/db/?f=f4d08dec7918c79a391fb1898d50c57a2448d872
headset-mic: https://alsa-project.org/db/?f=4b1eeef821f39eea28071ac2f2c0babcf515ef14

Not sure if it matters, but I want to add that I'm using nvidia render offload with reverse PRIME support, the gpu has one DP and one HDMI port wired directly to it.

aaand, I hope I am writing this issue in correct place :D

Hello,

I came across an issue with custom built aplay (system one works OK on Ubuntu 18.04):

I have fetched both alsa-lib and alsa-utils repositories, built them now try to run:

path_to_aplay/aplay -C -D hw:0,8 -r 16000 -f S16_LE -c 2 tmp.wav -vvv

Immediately after the start it prints hw params and the error message saying:

arecord: pcm_read:2103: read errorL Input/output error

As I said system aplay works fine. Moreover I compared hw params for both system and this custom built aplay and they are exactly the same!

I also tried to built alsa-utils from debian package here I did:

apt source alsa-lib && sudo apt build-dep alsa-utils && fakeroot debian/rules clean && fakeroot debian/rules build && fakeroot debian/rules binary

All finished fine, now I repeated above steps for alsa-utils and here is a problem at fakeroot debian/rules binary step. At some point it stops with an error message saying:

dpkg-shlibdeps: error: no dependency information found for /usr/lib/libasound.co.s2 (used by debian/alsa-utils/usr/bin/alsaucm)

Does anybody have any idea what is going on here?