November 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] snd_pcm_hw_params resets microphone boost
by sonntex 13 Nov '18

13 Nov '18

I have small program that captures audio from a microphone. As my microphone is very sensitive, I prefer to mute the microphone boost before capturing. I open alsamixer and set volume of the microphone boost to zero, save settings and exit. Then I execute my program. I see that it resets volume of the microphone boost in snd_pcm_hw_params. What should I do resolve this problem? Where can I find default value and change it?

2 1

[alsa-devel] Realtek ALC294 Intel Sunrise Point-LP HD Audio driver - sound does not work
by Tomasz Przybył 13 Nov '18

13 Nov '18

Hello Devs Lots of users with Intel Sunrise Point-LP HD Audio driver (ALC294) (snd_hda_intel) have major issue. Not sound at all. Only crackling from external speakers OR silence from internal notebook speakers. Tried fix with extra boot flags does not work at all. Also affected Asus VivoBook R542UF ``` Machine: Type: Laptop System: ASUSTeK product: VivoBook 15_ASUS Laptop X542UF v: 1.0 serial: <filter> Mobo: ASUSTeK model: X542UF v: 1.0 serial: <filter> UEFI: American Megatrends v: X542UF.303 date: 03/15/2018 Audio: Device-1: Intel Sunrise Point-LP HD Audio driver: snd_hda_intel v: kernel bus ID: 00:1f.3 Sound Server: ALSA Kernel: 4.19 ``` ``` aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC294 Analog [ALC294 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 ``` Dmesg parts ``` [ 12.342528] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC294: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 12.342531] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 12.342533] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 12.342535] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 12.342536] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 12.342538] snd_hda_codec_realtek hdaudioC0D0: Mic=0x1b ``` ``` [ 12.634171] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input18 [ 12.634389] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input19 [ 12.634563] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input20 [ 12.634737] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input21 [ 12.634905] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input22 [ 12.635045] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input23 ``` Regards Tomasz

2 1

[alsa-devel] [PATCH v5 2/3] ALSA: hda: fix front speakers on Huawei MBXP.
by Ayman Bagabas 13 Nov '18

13 Nov '18

This patch solves bug 200501 'Only 2 of 4 speakers playing sound.' https://bugzilla.kernel.org/show_bug.cgi?id=200501 It enables the front speakers on Huawei Matebook X Pro laptops. These laptops come with Dolby Atmos sound system and these pins configuration enables the front speakers. Signed-off-by: Ayman Bagabas <ayman.bagabas(a)gmail.com> --- sound/pci/hda/patch_realtek.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index fa61674a5605..135c0826859b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5493,6 +5493,7 @@ enum { ALC298_FIXUP_TPT470_DOCK, ALC255_FIXUP_DUMMY_LINEOUT_VERB, ALC255_FIXUP_DELL_HEADSET_MIC, + ALC256_FIXUP_HUAWEI_MBXP_PINS, ALC295_FIXUP_HP_X360, ALC221_FIXUP_HP_HEADSET_MIC, }; @@ -5764,6 +5765,22 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_HEADSET_MIC }, + [ALC256_FIXUP_HUAWEI_MBXP_PINS] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + {0x12, 0x90a60130}, + {0x13, 0x40000000}, + {0x14, 0x90170110}, + {0x18, 0x411111f0}, + {0x19, 0x04a11040}, + {0x1a, 0x411111f0}, + {0x1b, 0x90170112}, + {0x1d, 0x40759a05}, + {0x1e, 0x411111f0}, + {0x21, 0x04211020}, + { } + } + }, [ALC269_FIXUP_ASUS_X101_FUNC] = { .type = HDA_FIXUP_FUNC, .v.func = alc269_fixup_x101_headset_mic, @@ -6594,6 +6611,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), + SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP", ALC256_FIXUP_HUAWEI_MBXP_PINS), SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */ #if 0 -- 2.17.2

2 1

[alsa-devel] using the softvol plugin with min_dB > 0
by Guillermo Rodriguez Garcia 13 Nov '18

13 Nov '18

Hi all, I have a board with a tlv320aic3106 codec and a digital mic. The tlv320aic3106 does not support hardware gain for the digital mic, so I am using the softvol plugin to provide this via software. I would like to setup softvol so that it applies a gain in a range that goes from approx +10dB to approx +40dB. The problem is that softvol only accepts negative values for min_dB, i.e. assumes that you *always* want to do attenuation, and that you might or might not want to have gain (max_dB can be zero or negative). Is there any reason for this, or is it just historical ? (I am aware that the original softvol plugin only supported attenuation, and that support for gain was added later) Is it possible to setup softvol to accept a positive min_dB value ? Best regards, Guillermo Rodriguez Garcia guille.rodriguez(a)gmail.com

2 1

[alsa-devel] Help with extplug transfer callback
by GitHub issues - opened 13 Nov '18

13 Nov '18

alsa-project/alsa-lib issue #2 was opened from dchabot: 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. Issue URL : https://github.com/alsa-project/alsa-lib/issues/2 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[alsa-devel] [PATCH 1/4] README: update Vinod's email
by Vinod Koul 13 Nov '18

13 Nov '18

Update email address in README from old invalid id Signed-off-by: Vinod Koul <vkoul(a)kernel.org> --- README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index 689ca75e07fd..8ea6c26f5381 100644 --- a/README +++ b/README @@ -1,7 +1,7 @@ README for tinycompress ======================= - vinod.koul(a)linux.intel.com - ========================== + vkoul(a)kernel.org + ================ 1. WHAT tinycompress is a userspace library for anyone who wants to use the ALSA -- 2.14.5

1 3

[alsa-devel] [PATCH] tinycompress: Update headers to include AUDIOCODEC_BESPOKE
by Charles Keepax 13 Nov '18

13 Nov '18

commit dbb6b94339e8 ("ALSA: compress: Add SND_AUDIOCODEC_BESPOKE") added an additional CODEC type for bespoke CODECs. Update the local headers to include this. Reported-by: Andrew Ford <andrew.ford(a)cirrus.com> Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- include/sound/compress_params.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/sound/compress_params.h b/include/sound/compress_params.h index 9802292..7286556 100644 --- a/include/sound/compress_params.h +++ b/include/sound/compress_params.h @@ -38,8 +38,9 @@ #define SND_AUDIOCODEC_IEC61937 ((__u32) 0x0000000B) #define SND_AUDIOCODEC_G723_1 ((__u32) 0x0000000C) #define SND_AUDIOCODEC_G729 ((__u32) 0x0000000D) +#define SND_AUDIOCODEC_BESPOKE ((__u32) 0x0000000E) -#define SND_AUDIOCODEC_MAX SND_AUDIOCODEC_G729 +#define SND_AUDIOCODEC_MAX SND_AUDIOCODEC_BESPOKE #define SND_AUDIOPROFILE_PCM ((__u32) 0x00000001) #define SND_AUDIOCHANMODE_MP3_MONO ((__u32) 0x00000001) -- 2.11.0

2 1

[alsa-devel] [PATCH - dmix v5 0/1] pcm: dmix: Add option to allow alignment of slave pointers
by twischer＠de.adit-jv.com 13 Nov '18

13 Nov '18

On 11/12/18 17:20, Takashi Iwai wrote: > Please provide your own sign-off when you submitting a patch, too. > > The subject line should be adjusted better to match with the change; > it's about adding an option to allow alignment of hwptr reporting. > > About the changes: > the term "hw_ptr_filter" might sound confusing. IMO, this is about > the (hw)ptr alignment, not about filtering. > Also, a too long option string can easily lead to a misspell :) > > After all, we do either "no" alignment, "roundup" or "rounddown", or > "auto" choice. > > > thanks, > > Takashi Subject changed. Sign-off added. Option changed to hw_ptr_alignment. Option values changed to no, roundup, rounddown, auto Best regards Timo

2 2

[alsa-devel] [PATCH] ALSA: oxfw: add support for APOGEE duet FireWire
by Takashi Sakamoto 13 Nov '18

13 Nov '18

This commit adds support for APOGEE duet FireWire, launched 2007, already discontinued. This model uses Oxford Semiconductor FW971 as its communication engine. Below is information on Configuration ROM of this unit. The unit supports some AV/C commands defined by Audio subunit specification and vendor dependent commands. $ ./hinawa-config-rom-printer /dev/fw1 { 'bus-info': { 'adj': False, 'bmc': False, 'chip_ID': 42949742248, 'cmc': False, 'cyc_clk_acc': 255, 'generation': 0, 'imc': False, 'isc': True, 'link_spd': 3, 'max_ROM': 0, 'max_rec': 64, 'name': '1394', 'node_vendor_ID': 987, 'pmc': False}, 'root-directory': [ ['VENDOR', 987], ['DESCRIPTOR', 'Apogee Electronics'], ['MODEL', 122333], ['DESCRIPTOR', 'Duet'], [ 'NODE_CAPABILITIES', { 'addressing': {'64': True, 'fix': True, 'prv': False}, 'misc': {'int': False, 'ms': False, 'spt': True}, 'state': { 'atn': False, 'ded': False, 'drq': True, 'elo': False, 'init': False, 'lst': True, 'off': False}, 'testing': {'bas': False, 'ext': False}}], [ 'UNIT', [ ['SPECIFIER_ID', 41005], ['VERSION', 65537], ['MODEL', 122333], ['DESCRIPTOR', 'Duet']]]]} Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/Kconfig | 1 + sound/firewire/oxfw/oxfw.c | 8 ++++++++ 2 files changed, 9 insertions(+) diff --git a/sound/firewire/Kconfig b/sound/firewire/Kconfig index 8a146b039276..44cedb65bb88 100644 --- a/sound/firewire/Kconfig +++ b/sound/firewire/Kconfig @@ -41,6 +41,7 @@ config SND_OXFW * Mackie(Loud) U.420/U.420d * TASCAM FireOne * Stanton Controllers & Systems 1 Deck/Mixer + * APOGEE duet FireWire To compile this driver as a module, choose M here: the module will be called snd-oxfw. diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index afb78d90384b..3d27f3378d5d 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -20,6 +20,7 @@ #define VENDOR_LACIE 0x00d04b #define VENDOR_TASCAM 0x00022e #define OUI_STANTON 0x001260 +#define OUI_APOGEE 0x0003db #define MODEL_SATELLITE 0x00200f @@ -397,6 +398,13 @@ static const struct ieee1394_device_id oxfw_id_table[] = { .vendor_id = OUI_STANTON, .model_id = 0x002000, }, + // APOGEE, duet FireWire + { + .match_flags = IEEE1394_MATCH_VENDOR_ID | + IEEE1394_MATCH_MODEL_ID, + .vendor_id = OUI_APOGEE, + .model_id = 0x01dddd, + }, { } }; MODULE_DEVICE_TABLE(ieee1394, oxfw_id_table); -- 2.19.1

2 1

[alsa-devel] [PATCH - dmix v4 0/1] pcm: dmix: Align slave_hw_ptr to slave period
by twischer＠de.adit-jv.com 12 Nov '18

12 Nov '18

Hi Takashi, in the following we are providing the patch as requested by you: On 11/6/18 17:32, Takashi Iwai wrote: > I guess we may provide an option for choosing one of the following > modes: > > - current default mode; > no latency, but wakeup may be delayed, and may require 2*periods > > - appl_ptr round up to the next period; > the current workaround for periods <= 2. > This imposes the start latency. > > - round down to the current period start; > No latency, but will drop a few samples at start. > > ... and ideally, provide a mode "auto" for choosing the appropriate > one depending on the situation by a smart guess. Please provide your feedback. Best regards Timo

2 2