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

[alsa-devel] Boundary calculation
by Ricardo Biehl Pasquali 17 Jul '18

17 Jul '18

Hello. I can't get the tricky boundary calculation. Perhaps I'm missing some obvious thing, or maybe it's really some circumvent for a specific case that was not commented. The current calculation for boundary is: boundary = buffer_size; while (boundary * 2 <= LONG_MAX - buffer_size) boundary *= 2; I've checked out some repositories, specially alsa-driver in ALSA git, and I realized this calculation exists at least since 2001. I guess it was Jaroslav who wrote. Visualization of the calculation (B = buffer_size): LONG_MAX ------------------------------- \______________/ \__/ B * 4 B \______/ B * 2 \__/ B Why isn't a simpler calculation used instead? e.g.: /* closest multiple of buffer size less or equal LONG_MAX */ boundary = LONG_MAX - LONG_MAX % buffer_size; LONG_MAX ------------------------------- \__________________________/ B * 6 Cheers! pasquali

3 2

Re: [alsa-devel] [PATCH RFC] usb: add usb_fill_iso_urb()
by Clemens Ladisch 17 Jul '18

17 Jul '18

Sebastian Andrzej Siewior wrote: > sound/ is (almost) the only part where struct usb_iso_packet_descriptor > init does not fit. It looks like it is done just before urb_submit() and > could be avoided there (moved to the init funtcion instead). For playback, the packet lengths change dynamically, because the nominal sample rate (let alone the actual sample rate) often is not an integer multiple of the 1 kHz/8 kHz USB frame rate. Regards, Clemens

1 0

[alsa-devel] [PATCH 0/3] Make the audio component binding more generic
by Takashi Iwai 16 Jul '18

16 Jul '18

Hi, this is a preliminiary patch set to convert the existing i915 / HD-audio component binding to be applicable to other drivers like radeon / amdgpu. This patchset itself doesn't change the functionality but only renames and split to a new drm_audio_component stuff from i915_audio_component. The actual usage of the new API will follow once after this one gets reviewed / accepted. The whole patches (including this patchset) are found in topic/hda-acomp branch of sound.git tree. BTW, since the whole stuff is about the audio binding, I suppose these will go through sound git tree. Let me know if anyone has concerns. Thanks! Takashi === Takashi Iwai (3): drm/i915: Split audio component to a generic type ALSA: hda/i915: Associate audio component with devres ALSA: hda: Make audio component support more generic drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_audio.c | 22 +- include/drm/drm_audio_component.h | 138 ++++++++++++ include/drm/i915_component.h | 85 +------- include/sound/hda_component.h | 61 ++++++ include/sound/hda_i915.h | 37 +--- include/sound/hdaudio.h | 6 +- sound/hda/Kconfig | 7 +- sound/hda/Makefile | 1 + sound/hda/hdac_component.c | 332 ++++++++++++++++++++++++++++ sound/hda/hdac_i915.c | 335 ++--------------------------- sound/pci/hda/patch_hdmi.c | 57 +++-- sound/soc/codecs/hdac_hdmi.c | 10 +- 13 files changed, 624 insertions(+), 468 deletions(-) create mode 100644 include/drm/drm_audio_component.h create mode 100644 include/sound/hda_component.h create mode 100644 sound/hda/hdac_component.c -- 2.18.0

2 7

Re: [alsa-devel] 答复: 答复: 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
by Takashi Iwai 16 Jul '18

16 Jul '18

On Tue, 10 Jul 2018 09:44:42 +0200, Qu, Jim wrote: > > Hi Takashi, > > I am not expert in audio driver, so I just update some test result, please help triage the issue. > > With audio runtime pm: What does this mean? Is it the stock 4.17.x (or 4.18-rc)? Please clarify your test environment at first: which kernel, which hardware setup. > 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm. > 2. cat /proc/asound/card0/eld* can get nothing. > > Without audio runtime pm: > 1. pactl can get available audio output/sink > 2. can get eld info from eld#0.1 > > IMO, the issue should be: > > Current operations like HDMI hotplug in/out, pactl command, they do > not access audio HW, so the audio could not resume back at this > period. Sorry, not understood. Why they don't access the audio hardware? > Therefore, upper software could not get HDMI ELD info, can select a available card/output sink. > I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question. As long as it's i915 and HD-audio, the hotplug and ELD info transfer doesn't trigger the runtime PM since it's done via the direct callback. And ELD value is cached in HD-audio side. The exception is that if the notification is done during the PM operation. But, the connection and ELD query is performed at the end of codec resume, hence it'll be covered there. So in theory, ELD information should be passed from the GPU to HD-audio no matter whether runtime PM is enabled or not. BTW, please stop top-posting. It makes the thread readability awfully worse. thanks, Takashi > > Thanks > JimQu > > ________________________________________ > 发件人: Takashi Iwai <tiwai(a)suse.de> > 发送时间: 2018年7月10日 1:09 > 收件人: Qu, Jim > 抄送: Daniel Vetter; Alex Deucher; alsa-devel(a)alsa-project.org; amd-gfx(a)lists.freedesktop.org; dri-devel(a)lists.freedesktop.org; Deucher, Alexander > 主题: Re: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id > > On Mon, 09 Jul 2018 18:05:09 +0200, > Qu, Jim wrote: > > > > Hi Takashi, > > > > Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME. > > > > Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend. > > > > Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up. > > OK, and it has all necessary patches including the one Lukas > suggested, right? > > If so, figure out what you're actually seeing as "PA could not detect > HDMI audio". For example, is it the HDMI (jack) detection (giving > false even if it's connected)? Or is it an error at opening the given > device? Does the driver give the proper ELD bytes as well as the jack > state? > > > Takashi > > > > > Thanks > > JimQu > > > > -----邮件原件----- > > 发件人: Takashi Iwai <tiwai(a)suse.de> > > 发送时间: 2018年7月9日 23:58 > > 收件人: Daniel Vetter <daniel(a)ffwll.ch> > > 抄送: Alex Deucher <alexdeucher(a)gmail.com>; alsa-devel(a)alsa-project.org; amd-gfx(a)lists.freedesktop.org; Qu, Jim <Jim.Qu(a)amd.com>; dri-devel(a)lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher(a)amd.com> > > 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id > > > > On Mon, 09 Jul 2018 17:56:43 +0200, > > Daniel Vetter wrote: > > > > > > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote: > > > > On Mon, 09 Jul 2018 15:58:51 +0200, > > > > Alex Deucher wrote: > > > > > > > > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu(a)amd.com> wrote: > > > > > > Hi Lukas, > > > > > > > > > > > > Thanks to your explanation, and see comments in line. > > > > > > > > > > > > > > > > > > Do you need to runtime resume the HDA controller even if user > > > > > > space isn't streaming audio? Why, and in which situation exactly? > > > > > > > > > > > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing. > > > > > > > > > > > > You're saying above that the HDA controller isn't runtime > > > > > > resumed on hotplug of a display. Is that necessary to retrieve ELD or something? > > > > > > I'm not sure if there's code in the HDA driver to acquire a > > > > > > runtime PM ref on HPD, but maybe it's necessary. Or maybe the > > > > > > code is there but somehow no HPD interrupt is received by the HDA driver? > > > > > > > > > > > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not. > > > > > > > > > > On the gfx side at least, we can get a hotplug event via ACPI > > > > > (depending on the OEM design) if displays are attached/detached > > > > > while the dGPU is powered down. I suppose the gfx driver could > > > > > call into the audio driver during one of those events. On the gfx > > > > > side at least we just generate the gfx hotplug event and let userspace deal with it. > > > > > > > > IMO, a more proper way would be to have the direct communication > > > > between the graphics driver and the audio driver like i915 driver > > > > does. Then the audio driver can get plug/unplug event at more > > > > accurate timing without races. > > > > > > > > (Though, it will cause another mess wrt the weak module dependency, > > > > but it's another story :) > > > > > > Just don't do what snd-hda-intel did and instead implement the > > > component stuff properly :-) > > > > A patch is welcome :) > > > > > > thanks, > > > > Takashi > > > > > -Daniel > > > > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > Thanks > > > > > > JimQu > > > > > > > > > > > > ________________________________________ > > > > > > 发件人: Lukas Wunner <lukas(a)wunner.de> > > > > > > 发送时间: 2018年7月9日 17:27 > > > > > > 收件人: Qu, Jim > > > > > > 抄送: alsa-devel(a)alsa-project.org; > > > > > > dri-devel(a)lists.freedesktop.org; Deucher, Alexander; > > > > > > amd-gfx(a)lists.freedesktop.org > > > > > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to > > > > > > bound gpu client id > > > > > > > > > > > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote: > > > > > >> Now, I found the audio device will auto suspend even if the gpu > > > > > >> is active, and if I plug in a HDMI device it also do not resume back. > > > > > >> > > > > > >> 1. Did you encounter similar issue before? > > > > > >> 2. audio will auto suspend as default at beginning of boot, is > > > > > >> it expect behaviour? > > > > > > > > > > > > Yes, that's expected. Once you start streaming audio to > > > > > > attached displays, user space opens the codec device and this > > > > > > causes the HDA controller to runtime resume. If the discrete > > > > > > GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio. > > > > > > > > > > > > Do you need to runtime resume the HDA controller even if user > > > > > > space isn't streaming audio? Why, and in which situation exactly? > > > > > > > > > > > > You're saying above that the HDA controller isn't runtime > > > > > > resumed on hotplug of a display. Is that necessary to retrieve ELD or something? > > > > > > I'm not sure if there's code in the HDA driver to acquire a > > > > > > runtime PM ref on HPD, but maybe it's necessary. Or maybe the > > > > > > code is there but somehow no HPD interrupt is received by the HDA driver? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Lukas > > > > > > _______________________________________________ > > > > > > dri-devel mailing list > > > > > > dri-devel(a)lists.freedesktop.org > > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > _______________________________________________ > > > > > Alsa-devel mailing list > > > > > Alsa-devel(a)alsa-project.org > > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > > _______________________________________________ > > > > dri-devel mailing list > > > > dri-devel(a)lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > > > [2 pactl_with_runtimepm <application/octet-stream (base64)>] >

4 18

[alsa-devel] [V2 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to replace PCI_CLASS_DISPLAY_VGA
by Jim Qu 16 Jul '18

16 Jul '18

Except PCI_CLASS_DISPLAY_VGA, some PCI class is sometimes PCI_CLASS_DISPLAY_3D or PCI_CLASS_DISPLAY_OTHER. Signed-off-by: Jim Qu <Jim.Qu(a)amd.com> --- sound/pci/hda/hda_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 1ae1850..14733ff 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1429,7 +1429,7 @@ static struct pci_dev *get_bound_vga(struct pci_dev *pci) p = pci_get_domain_bus_and_slot(pci_domain_nr(pci->bus), pci->bus->number, 0); if (p) { - if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA) + if ((p->class >> 16) == PCI_BASE_CLASS_DISPLAY) return p; pci_dev_put(p); } -- 2.7.4

5 9

[alsa-devel] [PATCH] ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk
by yokota.hgml＠gmail.com 16 Jul '18

16 Jul '18

This adds some required quirk when uses headset or headphone on Panasonic CF-SZ6. Signed-off-by: YOKOTA Hiroshi <yokota.hgml(a)gmail.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)

2 1

[alsa-devel] [PATCH] ALSA: hda: add mute led support for HP ProBook 455 G5
by Po-Hsu Lin 16 Jul '18

16 Jul '18

Audio mute led does not work on HP ProBook 455 G5, this can be fixed by using CXT_FIXUP_MUTE_LED_GPIO to support it. BugLink: https://bugs.launchpad.net/bugs/1781763 Reported-by: James Buren Signed-off-by: Po-Hsu Lin <po-hsu.lin(a)canonical.com> --- sound/pci/hda/patch_conexant.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index e7fcfc3..f641c20 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -964,6 +964,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = { SND_PCI_QUIRK(0x103c, 0x8115, "HP Z1 Gen3", CXT_FIXUP_HP_GATE_MIC), SND_PCI_QUIRK(0x103c, 0x814f, "HP ZBook 15u G3", CXT_FIXUP_MUTE_LED_GPIO), SND_PCI_QUIRK(0x103c, 0x822e, "HP ProBook 440 G4", CXT_FIXUP_MUTE_LED_GPIO), + SND_PCI_QUIRK(0x103c, 0x836e, "HP ProBook 455 G5", CXT_FIXUP_MUTE_LED_GPIO), SND_PCI_QUIRK(0x103c, 0x8299, "HP 800 G3 SFF", CXT_FIXUP_HP_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x103c, 0x829a, "HP 800 G3 DM", CXT_FIXUP_HP_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x103c, 0x8455, "HP Z2 G4", CXT_FIXUP_HP_MIC_NO_PRESENCE), -- 2.7.4

2 1

[alsa-devel] [PATCH 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to cover more display adapters
by Jim Qu 16 Jul '18

16 Jul '18

Signed-off-by: Jim Qu <Jim.Qu(a)amd.com> --- sound/pci/hda/hda_intel.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 1ae1850..e0064567 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -31,7 +31,7 @@ * CHANGES: * * 2004.12.01 Major rewrite by tiwai, merged the work of pshou - * + * */ #include <linux/delay.h> @@ -390,8 +390,8 @@ static char *driver_short_names[] = { [AZX_DRIVER_SIS] = "HDA SIS966", [AZX_DRIVER_ULI] = "HDA ULI M5461", [AZX_DRIVER_NVIDIA] = "HDA NVidia", - [AZX_DRIVER_TERA] = "HDA Teradici", - [AZX_DRIVER_CTX] = "HDA Creative", + [AZX_DRIVER_TERA] = "HDA Teradici", + [AZX_DRIVER_CTX] = "HDA Creative", [AZX_DRIVER_CTHDA] = "HDA Creative", [AZX_DRIVER_CMEDIA] = "HDA C-Media", [AZX_DRIVER_GENERIC] = "HD-Audio Generic", @@ -1429,7 +1429,7 @@ static struct pci_dev *get_bound_vga(struct pci_dev *pci) p = pci_get_domain_bus_and_slot(pci_domain_nr(pci->bus), pci->bus->number, 0); if (p) { - if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA) + if ((p->class >> 16) == PCI_BASE_CLASS_DISPLAY) return p; pci_dev_put(p); } -- 2.7.4

5 13

[alsa-devel] [PATCH 0/5] UAC3: Add Selectors and Processing Units.
by Jorge Sanjuan 16 Jul '18

16 Jul '18

This patchset is motivated by the addition of Multi Function Processing Units (MFPU) to an UAC3 topology where there could be signal processing algorithims applied to the audio signal. The MFPUs themself don't provide any useful control, they offer a description of what algorithims it supports and it is for Selector Units to take the bypass control of the dry (unprocessed) signal and the modified one. Moreover, Up/Down mixers may be needed in this topologies to control which outputs of the logical output cluster from the MFPU are to be passed as the final modified audio signal. These patches add support for Selector Units and Processing units for UAC3 and adds a couple fixes that I found while implemeting them: 1) Defualt naming of the virtual terminals was not accurate due to codes overlap between the three UAC standards. 2) UAC2 parsing of processing units was using UAC1 controls bitmap. Based on: next-20180711 Jorge Sanjuan (5): ALSA: usb-audio: Add support for Selector Units in UAC3 ALSA: usb-audio: Processing Unit controls parsing in UAC2 ALSA: usb-audio: Add support for Processing Units in UAC3 ALSA: usb-audio: Unify virtual type units type to UAC3 values ALSA: usb-audio: Tidy up logic for Processing Unit min/max values include/linux/usb/audio-v3.h | 15 +++ include/uapi/linux/usb/audio.h | 49 ++++++++-- sound/usb/mixer.c | 212 +++++++++++++++++++++++++++++++++-------- 3 files changed, 225 insertions(+), 51 deletions(-) -- 2.11.0

2 6

[alsa-devel] Applied "ASoC: hdmi-codec: fix routing" to the asoc tree
by Mark Brown 16 Jul '18

16 Jul '18

The patch ASoC: hdmi-codec: fix routing has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From d30e23d69981a4b665f5ce8711335df986576389 Mon Sep 17 00:00:00 2001 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Sat, 14 Jul 2018 16:01:06 +0100 Subject: [PATCH] ASoC: hdmi-codec: fix routing Commit 943fa0228252 ("ASoC: hdmi-codec: Use different name for playback streams") broke hdmi-codec's routing between it's output "TX" widget and the S/PDIF or I2S streams by renaming the streams. Whether an error occurs or not is dependent on whether there is another widget called "Playback" registered by some other component - if there is, that widget will be (incorrectly) bound to the HDMI codec's "TX" output widget. If we end up connecting "TX" incorrectly, it can result in components not being started, causing no audio output. Since the I2S and S/PDIF streams now have different names, we can't use a static route at component level to describe the relationship, so arrange to dynamically create the route when the DAI driver is probed. Fixes: 943fa0228252 ("ASoC: hdmi-codec: Use different name for playback streams") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/hdmi-codec.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c index 6fa11888672d..3e5b12de71bb 100644 --- a/sound/soc/codecs/hdmi-codec.c +++ b/sound/soc/codecs/hdmi-codec.c @@ -291,10 +291,6 @@ static const struct snd_soc_dapm_widget hdmi_widgets[] = { SND_SOC_DAPM_OUTPUT("TX"), }; -static const struct snd_soc_dapm_route hdmi_routes[] = { - { "TX", NULL, "Playback" }, -}; - enum { DAI_ID_I2S = 0, DAI_ID_SPDIF, @@ -689,9 +685,23 @@ static int hdmi_codec_pcm_new(struct snd_soc_pcm_runtime *rtd, return snd_ctl_add(rtd->card->snd_card, kctl); } +static int hdmi_dai_probe(struct snd_soc_dai *dai) +{ + struct snd_soc_dapm_context *dapm; + struct snd_soc_dapm_route route = { + .sink = "TX", + .source = dai->driver->playback.stream_name, + }; + + dapm = snd_soc_component_get_dapm(dai->component); + + return snd_soc_dapm_add_routes(dapm, &route, 1); +} + static const struct snd_soc_dai_driver hdmi_i2s_dai = { .name = "i2s-hifi", .id = DAI_ID_I2S, + .probe = hdmi_dai_probe, .playback = { .stream_name = "I2S Playback", .channels_min = 2, @@ -707,6 +717,7 @@ static const struct snd_soc_dai_driver hdmi_i2s_dai = { static const struct snd_soc_dai_driver hdmi_spdif_dai = { .name = "spdif-hifi", .id = DAI_ID_SPDIF, + .probe = hdmi_dai_probe, .playback = { .stream_name = "SPDIF Playback", .channels_min = 2, @@ -733,8 +744,6 @@ static int hdmi_of_xlate_dai_id(struct snd_soc_component *component, static const struct snd_soc_component_driver hdmi_driver = { .dapm_widgets = hdmi_widgets, .num_dapm_widgets = ARRAY_SIZE(hdmi_widgets), - .dapm_routes = hdmi_routes, - .num_dapm_routes = ARRAY_SIZE(hdmi_routes), .of_xlate_dai_id = hdmi_of_xlate_dai_id, .idle_bias_on = 1, .use_pmdown_time = 1, -- 2.18.0.rc2

1 0