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

[alsa-devel] [PATCH 00/11] Add ZxR support + bugfixes
by Connor McAdams 08 Oct '18

08 Oct '18

This patch series adds support for the Sound Blaster ZxR, as well as a few bug fixes. This should be the last ca0132 based Creative card that needed support to be added. Also, I did check to make sure each patch compiles properly this time, but you can check yourself just to be sure. :) Connor McAdams (11): ALSA: hda/ca0132 - Fix AE-5 control type ALSA: hda/ca0132 - Fix surround sound with output effects ALSA: hda/ca0132 - Add ZxR quirks + new quirk check function ALSA: hda/ca0132 - Add ZxR pincfg ALSA: hda/ca0132 - Add DBpro hda_codec_ops ALSA: hda/ca0132 - Add ZxR init commands ALSA: hda/ca0132 - Add ZxR DSP post-download commands ALSA: hda/ca0132 - Add ZxR input/output select commands ALSA: hda/ca0132 - Remove input select enum for ZxR ALSA: hda/ca0132 - Add ZxR 600 ohm gain control ALSA: hda/ca0132 - Add ZxR exit commands sound/pci/hda/patch_ca0132.c | 369 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 345 insertions(+), 24 deletions(-) -- 2.7.4

3 17

Re: [alsa-devel] Microphone detected, but no output for all ASUS G751xx with ALC668 chipset
by Connor McAdams 08 Oct '18

08 Oct '18

I might not get around to writing the fix myself, but, here's the COEF's from within Windows. I've marked the ones missing inside the main init function. So, if anyone else wants to add these in, feel free. On Wed, Sep 12, 2018 at 1:16 PM, Håvard <hovardslill(a)gmail.com> wrote: > That was without running the program (sorry) > > This is output when running program: > > Before there was no "Current verb...." > They came when I opened up windows microphone settings. (something I didn't > do before) > > -Håvard > > Den ons. 12. sep. 2018 kl. 19:11 skrev Håvard <hovardslill(a)gmail.com>: >> >> I think this is right! >> >> I first booted up, then tested speakers (That I could not hear) and then >> tested microphone (Which worked perfectly) in windows settings. >> >> (My first email was dissaproved as it was too large) >> >> Den ons. 12. sep. 2018 kl. 19:05 skrev Håvard <hovardslill(a)gmail.com>: >>> >>> I think this is right! >>> >>> I first booted up, then tested speakers (That I could not hear) and then >>> tested microphone (Which worked perfectly) in windows settings. >>> >>> -Håvard >>> >>> Den ons. 12. sep. 2018 kl. 18:49 skrev Connor McAdams >>> <conmanx360(a)gmail.com>: >>>> >>>> Also, sorry to keep sending more replies, make sure the only trace you >>>> have on is vfio_region_write, and not the read one. The read spams up >>>> the console. >>>> >>>> On Wed, Sep 12, 2018 at 12:43 PM, Connor McAdams <conmanx360(a)gmail.com> >>>> wrote: >>>> > Reason being, it may not have identified the CORB buffer properly or >>>> > something. That's very odd to have no data. Never seen that before. >>>> > >>>> > On Wed, Sep 12, 2018 at 12:42 PM, Connor McAdams >>>> > <conmanx360(a)gmail.com> wrote: >>>> >> Could you try again and make a copy of your terminal output? >>>> >> >>>> >> On Wed, Sep 12, 2018 at 12:41 PM, Håvard <hovardslill(a)gmail.com> >>>> >> wrote: >>>> >>> Hi again. >>>> >>> Sorry for not noticing all files were empty, did it not run for long >>>> >>> enough? >>>> >>> >>>> >>> -Håvard >>>> >>> >>>> >>> Den ons. 12. sep. 2018 kl. 18:39 skrev Håvard >>>> >>> <hovardslill(a)gmail.com>: >>>> >>>> >>>> >>>> Sorry my bad again it was working perfectly, just missed a step. >>>> >>>> >>>> >>>> I'll add the dumps as an attatchment. I had both external headset >>>> >>>> and >>>> >>>> microphone plugged in and let the VM run in the background for >>>> >>>> ~30min while >>>> >>>> doing other stuff. I did not play music or test my microphone in >>>> >>>> the VM >>>> >>>> either, If i did anything wrong, please tell me! >>>> >>>> >>>> >>>> It stopped at 0x104f4 >>>> >>>> >>>> >>>> -Håvard >>>> >>>> >>>> >>>> Den ons. 12. sep. 2018 kl. 00:31 skrev Connor McAdams >>>> >>>> <conmanx360(a)gmail.com>: >>>> >>>>> >>>> >>>>> Hm.... that's odd. They should show up in the folder you ran the >>>> >>>>> command from. Does your console show any "DumpMem entered..." or >>>> >>>>> something like that? You may have a permissions error. I've had >>>> >>>>> some >>>> >>>>> people report that as an issue before. >>>> >>>>> >>>> >>>>> On Tue, Sep 11, 2018 at 5:08 PM, Håvard <hovardslill(a)gmail.com> >>>> >>>>> wrote: >>>> >>>>> > Hi! >>>> >>>>> > >>>> >>>>> > Took a while, but I think I got it working. Did not see any >>>> >>>>> > "frame[xx]" >>>> >>>>> > files though. What dumps do you want? >>>> >>>>> > >>>> >>>>> > -Håvard >>>> >>>>> > >>>> >>>>> > Den tir. 11. sep. 2018 kl. 21:27 skrev Håvard >>>> >>>>> > <hovardslill(a)gmail.com>: >>>> >>>>> >> >>>> >>>>> >> Sorry about that, I forgot to enable a kernel config... >>>> >>>>> >> >>>> >>>>> >> -Håvard >>>> >>>>> >> >>>> >>>>> >> Den tir. 11. sep. 2018 kl. 21:20 skrev Connor McAdams >>>> >>>>> >> <conmanx360(a)gmail.com>: >>>> >>>>> >>> >>>> >>>>> >>> When it's bound as a stub, it shouldn't show up in alsamixer >>>> >>>>> >>> controls. >>>> >>>>> >>> You can check what module is loaded by doing lspci -v . It >>>> >>>>> >>> should say >>>> >>>>> >>> kernel driver in use: pci-stub. Also, did you run the >>>> >>>>> >>> vfio-bind >>>> >>>>> >>> script >>>> >>>>> >>> before trying it? >>>> >>>>> >>> >>>> >>>>> >>> On Tue, Sep 11, 2018 at 3:18 PM, Håvard >>>> >>>>> >>> <hovardslill(a)gmail.com> >>>> >>>>> >>> wrote: >>>> >>>>> >>> > Thank you for the offer! >>>> >>>>> >>> > >>>> >>>>> >>> > I run gentoo, but your github guide is very useful. I can't >>>> >>>>> >>> > seem to >>>> >>>>> >>> > bind my >>>> >>>>> >>> > audio driver to a pci-stud. Is the Sound card still supposed >>>> >>>>> >>> > to >>>> >>>>> >>> > function as >>>> >>>>> >>> > normal when I (think I) have bound it to a stud. >>>> >>>>> >>> > >>>> >>>>> >>> > -Håvard >>>> >>>>> >>> > >>>> >>>>> >>> > Den tir. 11. sep. 2018 kl. 20:26 skrev Connor McAdams >>>> >>>>> >>> > <conmanx360(a)gmail.com>: >>>> >>>>> >>> >> >>>> >>>>> >>> >> One thing you could try, is using the program I used to >>>> >>>>> >>> >> reverse >>>> >>>>> >>> >> engineer the Sound Blaster Z series of cards, QemuHDADump. >>>> >>>>> >>> >> If your >>>> >>>>> >>> >> processor supports pci-passthrough with a virtual machine, >>>> >>>>> >>> >> you >>>> >>>>> >>> >> could >>>> >>>>> >>> >> run a Windows virtual machine with the sound card in it and >>>> >>>>> >>> >> capture >>>> >>>>> >>> >> the commands. I'd be willing to look through the dumps to >>>> >>>>> >>> >> see if >>>> >>>>> >>> >> there >>>> >>>>> >>> >> are any special verbs or anything. >>>> >>>>> >>> >> >>>> >>>>> >>> >> You can find the program here: >>>> >>>>> >>> >> https://github.com/Conmanx360/QemuHDADump >>>> >>>>> >>> >> >>>> >>>>> >>> >> Let me know. >>>> >>>>> >>> >> >>>> >>>>> >>> >> On Tue, Sep 11, 2018 at 2:15 PM, Håvard >>>> >>>>> >>> >> <hovardslill(a)gmail.com> >>>> >>>>> >>> >> wrote: >>>> >>>>> >>> >> > Sorry, my gmail didn't update so I wrote my response >>>> >>>>> >>> >> > before I >>>> >>>>> >>> >> > read >>>> >>>>> >>> >> > your >>>> >>>>> >>> >> > last one. >>>> >>>>> >>> >> > >>>> >>>>> >>> >> > It is a separate mic port as the G751JT doesn't have any >>>> >>>>> >>> >> > headset >>>> >>>>> >>> >> > multijacks. >>>> >>>>> >>> >> > >>>> >>>>> >>> >> > I'll try and dig around in the kernel! Thanks for the >>>> >>>>> >>> >> > tip! >>>> >>>>> >>> >> > >>>> >>>>> >>> >> > -Håvard >>>> >>>>> >>> >> > >>>> >>>>> >>> >> > Den tir. 11. sep. 2018 kl. 20:09 skrev Håvard >>>> >>>>> >>> >> > <hovardslill(a)gmail.com>: >>>> >>>>> >>> >> > >>>> >>>>> >>> >> >> Thank you for taking your time and trying to help! :) >>>> >>>>> >>> >> >> >>>> >>>>> >>> >> >> Do you know where I can ask around for more help on the >>>> >>>>> >>> >> >> issue? >>>> >>>>> >>> >> >> I >>>> >>>>> >>> >> >> don't >>>> >>>>> >>> >> >> want to give up yet. >>>> >>>>> >>> >> >> >>>> >>>>> >>> >> >> -Håvard >>>> >>>>> >>> >> >> >>>> >>>>> >>> >> >> Den tir. 11. sep. 2018 kl. 20:02 skrev Takashi Iwai >>>> >>>>> >>> >> >> <tiwai(a)suse.de>: >>>> >>>>> >>> >> >> >>>> >>>>> >>> >> >>> On Tue, 11 Sep 2018 19:14:37 +0200, >>>> >>>>> >>> >> >>> Håvard wrote: >>>> >>>>> >>> >> >>> > >>>> >>>>> >>> >> >>> > Yes, microphone gets detected instantly and it >>>> >>>>> >>> >> >>> > automatically >>>> >>>>> >>> >> >>> > changes >>>> >>>>> >>> >> >>> > to >>>> >>>>> >>> >> >>> it >>>> >>>>> >>> >> >>> > in pavucontrol. >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> Then it likely requires some additional initialization >>>> >>>>> >>> >> >>> outside >>>> >>>>> >>> >> >>> HD-audio. It's hard to know, as it's pretty much >>>> >>>>> >>> >> >>> vendor-specific. >>>> >>>>> >>> >> >>> You can dig down the Windows, but I have no idea about >>>> >>>>> >>> >> >>> Windows >>>> >>>>> >>> >> >>> implementation, so can't give any hints, unfortunately. >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> Takashi >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> > >>>> >>>>> >>> >> >>> > Den tir. 11. sep. 2018 kl. 18:52 skrev Takashi Iwai >>>> >>>>> >>> >> >>> > <tiwai(a)suse.de>: >>>> >>>>> >>> >> >>> > >>>> >>>>> >>> >> >>> > > On Tue, 11 Sep 2018 18:40:23 +0200, >>>> >>>>> >>> >> >>> > > Håvard wrote: >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > > Thank you for replying! >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > > Enabling loopback in alsamixer: >>>> >>>>> >>> >> >>> > > > http://i.imgur.com/lNo6e7T.png >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > > And unmuting more and more things in "Mic >>>> >>>>> >>> >> >>> > > > Playback >>>> >>>>> >>> >> >>> > > > Volume" >>>> >>>>> >>> >> >>> > > > in >>>> >>>>> >>> >> >>> > > hdaanalyzer: >>>> >>>>> >>> >> >>> > > > http://i.imgur.com/H0HiOhy.png >>>> >>>>> >>> >> >>> > > > made white noise come from the headset. However >>>> >>>>> >>> >> >>> > > > it did >>>> >>>>> >>> >> >>> > > > not >>>> >>>>> >>> >> >>> > > > change or >>>> >>>>> >>> >> >>> > > react >>>> >>>>> >>> >> >>> > > > at all when I talked or even muted the microphone >>>> >>>>> >>> >> >>> > > > physically. >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > > I couldn't find "Mic Playback Switch" anywhere in >>>> >>>>> >>> >> >>> > > > either >>>> >>>>> >>> >> >>> > > > alsamixer >>>> >>>>> >>> >> >>> or >>>> >>>>> >>> >> >>> > > > hdaanalyzer. >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > > It's a mixer mute switch. >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > > > The microphone works perfectly fine under >>>> >>>>> >>> >> >>> > > > Windows, so I >>>> >>>>> >>> >> >>> > > > don't >>>> >>>>> >>> >> >>> > > > think >>>> >>>>> >>> >> >>> it is >>>> >>>>> >>> >> >>> > > > the mic pin. >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > > But the fact above indicates the possibility of the >>>> >>>>> >>> >> >>> > > wrong >>>> >>>>> >>> >> >>> > > pin, >>>> >>>>> >>> >> >>> > > too. >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > > Does the jack detection of the ext mic pin work? >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > > Takashi >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > > -Håvard >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > > Den man. 10. sep. 2018 kl. 22:39 skrev Takashi >>>> >>>>> >>> >> >>> > > > Iwai >>>> >>>>> >>> >> >>> > > > <tiwai(a)suse.de >>>> >>>>> >>> >> >>> >: >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > > > On Thu, 06 Sep 2018 20:44:30 +0200, >>>> >>>>> >>> >> >>> > > > > Håvard wrote: >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > Additional relevant info: >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > A similar issue was also discussed three >>>> >>>>> >>> >> >>> > > > > > years ago >>>> >>>>> >>> >> >>> > > > > > on >>>> >>>>> >>> >> >>> > > > > > Sun >>>> >>>>> >>> >> >>> > > > > > Jun >>>> >>>>> >>> >> >>> > > 17:15:54 >>>> >>>>> >>> >> >>> > > > > CEST >>>> >>>>> >>> >> >>> > > > > > 2015 and was about his surround sound setup, >>>> >>>>> >>> >> >>> > > > > > but did >>>> >>>>> >>> >> >>> > > > > > not >>>> >>>>> >>> >> >>> > > > > > touch >>>> >>>>> >>> >> >>> on the >>>> >>>>> >>> >> >>> > > > > > external microphone problem: >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093317.html >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > alsa-info.sh: >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >>> http://www.alsa-project.org/db/?f=1d8616ba5977308e03db6c3a86e36e9e9b38d6f0 >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > Graph of ALC668 chipset from hdaanalyzer: >>>> >>>>> >>> >> >>> > > > > > http://i.imgur.com/c08DNJW.png >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > setting alsa-mode[1-8] does nothing to help >>>> >>>>> >>> >> >>> > > > > > the >>>> >>>>> >>> >> >>> > > > > > issue. >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > There are several of similar bug reports >>>> >>>>> >>> >> >>> > > > > > around the >>>> >>>>> >>> >> >>> > > > > > web >>>> >>>>> >>> >> >>> experiencing >>>> >>>>> >>> >> >>> > > > > > similar issues, and on different distros. >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > Microphone works perfectly in windows >>>> >>>>> >>> >> >>> > > > > > >>>> >>>>> >>> >> >>> > > > > > I have a ASUS ROG G751JT, but this problem >>>> >>>>> >>> >> >>> > > > > > seems to >>>> >>>>> >>> >> >>> > > > > > happen >>>> >>>>> >>> >> >>> > > > > > with >>>> >>>>> >>> >> >>> all >>>> >>>>> >>> >> >>> > > > > laptops >>>> >>>>> >>> >> >>> > > > > > under the G751 name. >>>> >>>>> >>> >> >>> > > > > >>>> >>>>> >>> >> >>> > > > > When you enable the loopback volume and switch, >>>> >>>>> >>> >> >>> > > > > and >>>> >>>>> >>> >> >>> > > > > unmute/adjust >>>> >>>>> >>> >> >>> "Mic >>>> >>>>> >>> >> >>> > > > > Playback Volume", and "Mic Playback Switch", do >>>> >>>>> >>> >> >>> > > > > you >>>> >>>>> >>> >> >>> > > > > hear >>>> >>>>> >>> >> >>> > > > > the >>>> >>>>> >>> >> >>> > > > > input >>>> >>>>> >>> >> >>> > > > > from the ext mic? It's a route directly from >>>> >>>>> >>> >> >>> > > > > NID 0x18 >>>> >>>>> >>> >> >>> > > > > to >>>> >>>>> >>> >> >>> > > > > the >>>> >>>>> >>> >> >>> mixer >>>> >>>>> >>> >> >>> > > > > NID 0x0b, then output mixer NID 0x0c, then >>>> >>>>> >>> >> >>> > > > > outputs. >>>> >>>>> >>> >> >>> > > > > So >>>> >>>>> >>> >> >>> > > > > this >>>> >>>>> >>> >> >>> > > > > can >>>> >>>>> >>> >> >>> be >>>> >>>>> >>> >> >>> > > > > used to verify the hardware routing. >>>> >>>>> >>> >> >>> > > > > >>>> >>>>> >>> >> >>> > > > > If you don't hear via this route, it means that >>>> >>>>> >>> >> >>> > > > > the >>>> >>>>> >>> >> >>> > > > > input >>>> >>>>> >>> >> >>> > > > > from >>>> >>>>> >>> >> >>> the ext >>>> >>>>> >>> >> >>> > > > > mic pin itself is broken, and it implies that >>>> >>>>> >>> >> >>> > > > > something >>>> >>>>> >>> >> >>> > > > > outside >>>> >>>>> >>> >> >>> > > > > HD-audio codec. >>>> >>>>> >>> >> >>> > > > > >>>> >>>>> >>> >> >>> > > > > >>>> >>>>> >>> >> >>> > > > > Takashi >>>> >>>>> >>> >> >>> > > > > >>>> >>>>> >>> >> >>> > > > [2 <text/html; UTF-8 (quoted-printable)>] >>>> >>>>> >>> >> >>> > > > >>>> >>>>> >>> >> >>> > > >>>> >>>>> >>> >> >>> > [2 <text/html; UTF-8 (quoted-printable)>] >>>> >>>>> >>> >> >>> > >>>> >>>>> >>> >> >>> >>>> >>>>> >>> >> >> >>>> >>>>> >>> >> > _______________________________________________ >>>> >>>>> >>> >> > Alsa-devel mailing list >>>> >>>>> >>> >> > Alsa-devel(a)alsa-project.org >>>> >>>>> >>> >> > >>>> >>>>> >>> >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

3 26

[alsa-devel] [PATCH v2 0/5] ASoC: qdsp6: add compress offload support
by Srinivas Kandagatla 05 Oct '18

05 Oct '18

This patchset adds support to very basic MP3 playback compress offload support via QDSP ASM module. Tested this patchset on DB410c with APQ8016 and DB820c with APQ8096 using tinycompress library. Adding other codec support should be trivial w.r.t qdsp6 side, however there are other dependencies like compress UAPI header changes and FastRPC which are being worked in parallel. Once ready will post them! thanks, srini Changes since v1 (https://patchwork.kernel.org/cover/10585805/) - added support to snd_compr_set_runtime_buffer() - make use of generic copy function - few trivial cleanups suggested by Vinod Koul Srinivas Kandagatla (5): ALSA: soc-compress: add support to snd_compr_set_runtime_buffer() ALSA: compress: make use of runtime buffer for copy ASoC: q6asm-dai: dt-bindings: Add support to compress dais ASoC: qdsp6: q6asm: add support to MP3 format ASoC: qdsp6: q6asm-dai: Add support to compress offload .../devicetree/bindings/sound/qcom,q6asm.txt | 27 ++ include/sound/compress_driver.h | 19 + sound/core/compress_offload.c | 18 +- sound/soc/qcom/Kconfig | 1 + sound/soc/qcom/qdsp6/q6asm-dai.c | 377 +++++++++++++++++- sound/soc/qcom/qdsp6/q6asm.c | 5 + 6 files changed, 443 insertions(+), 4 deletions(-) -- 2.19.0

2 9

[alsa-devel] Problem and Patch for B&W PX Bluetooth Headphones
by Nicolas Herochao 04 Oct '18

04 Oct '18

Hello, I'm writing this mail because of a Crash when connecting the B&W PX headphones via usb. Half a year ago this used to work with Linux after setting the default sample rate of pulseaudio to 48000k. A Launchpad Bug seems to describe this exact issue (detailed description below): https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1773697. It pointed me to the right direction, and today I have successfully compiled and tested a small patch that fixes the errors while also setting the sample rate to 48000k, making these headphones plug&play on any newer firmware. They sound awesome via USB! I would like to submit this patch, but it would be my first contribution and it could potentially break the B&W PX on older firmware. I can't test it since I see no obvious ways to downgrade the firmware. The automatic detection of these headphones always worked except for the sample-rate and perhaps the worst result is that old firmware will show a non-functional microphone, like on Windows. So I decided to first present the patch on this mailing list and ask for feedback and help. If anyone wants to pick the patch up, I'd appreciate that as well. My questions: * Can a quirk somehow handle multiple firmware versions of a usb device? * If not: Will this quirk allow old firmware to work out of the box but show a non-functional microphone? (And is that okay?) Thanks for your time and any feedback you can provide! Sincerely, Nicolas PS: more detail on the cause of the issue: ------ A quirk in snd-usb-audio was added to automate setting sample rate to 4800k and remove the previously exposed nonfunctional microphone: commit 240a8af929c7c57dcde28682725b29cf8474e8e5 https://lore.kernel.org/patchwork/patch/919689/ However the headphones where updated shortly after that to remove the unintentional microphone functionality. I guess because of this the headphones now crash when connecting them via USB while the quirk is active with the following dmesg errors: snd-usb-audio: probe of 2-3:1.0 failed with error -22 usb 2-3: 2:1: cannot get min/max values for control 2 (id 2) --------------- Finally, here is the patch (based on the current mainline kernel and generated according to all Guidelines I could find) which fixes the quirk by removing the microphone part: ---------------- From 748587283db85e219902abf4ac012864005943c8 Mon Sep 17 00:00:00 2001 From: Nicolas Huaman <nicolas(a)herochao.de> Date: Fri, 28 Sep 2018 18:05:15 +0200 Subject: [PATCH 1/1] SOUND: update quirk for B&W PX to remove microphone Signed-off-by: Nicolas Huaman <nicolas(a)herochao.de> --- sound/usb/quirks-table.h | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 08aa78007020..849953e5775c 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -3346,19 +3346,14 @@ AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"), .ifnum = 0, .type = QUIRK_AUDIO_STANDARD_MIXER, }, - /* Capture */ - { - .ifnum = 1, - .type = QUIRK_IGNORE_INTERFACE, - }, /* Playback */ { - .ifnum = 2, + .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = &(const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S16_LE, .channels = 2, - .iface = 2, + .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_FILL_MAX | -- 2.19.0

2 1

[alsa-devel] [PATCH 0/7] Add devres support to card resources
by Takashi Iwai 04 Oct '18

04 Oct '18

Hi, here is the patchset containing the changes to support a device-managed resource management for ALSA card and memory pages. The actual code changes are identical with the previous RFC series, but a few documentation updates are included in this official set. Takashi === Takashi Iwai (7): ALSA: core: Add device-managed page allocator helper ALSA: core: Add managed card creation ALSA: intel8x0: Allocate resources with device-managed APIs ALSA: atiixp: Allocate resources with device-managed APIs ALSA: hda: Allocate resources with device-managed APIs ALSA: doc: Brush up the old writing-an-alsa-driver ALSA: doc: Add device-managed resource section .../kernel-api/writing-an-alsa-driver.rst | 340 ++++++++++-------- include/sound/core.h | 5 + include/sound/memalloc.h | 4 + sound/core/init.c | 95 ++++- sound/core/memalloc.c | 88 ++++- sound/pci/atiixp.c | 104 ++---- sound/pci/atiixp_modem.c | 104 ++---- sound/pci/hda/hda_controller.h | 1 - sound/pci/hda/hda_intel.c | 43 +-- sound/pci/intel8x0.c | 143 +++----- sound/pci/intel8x0m.c | 143 +++----- 11 files changed, 514 insertions(+), 556 deletions(-) -- 2.18.0

2 19

[alsa-devel] Thread spinning in kernel snd_pcm_link()/snd_pcm_unlink()
by Rob Duncan 02 Oct '18

02 Oct '18

I'm trying to address a bug where we end up with a thread spinning and consuming an entire cpu. The issue seems to be this code in sound/core/pcm_native.c: /* Writer in rwsem may block readers even during its waiting in queue, * and this may lead to a deadlock when the code path takes read sem * twice (e.g. one in snd_pcm_action_nonatomic() and another in * snd_pcm_stream_lock()). As a (suboptimal) workaround, let writer to * spin until it gets the lock. */ static inline void down_write_nonblock(struct rw_semaphore *lock) { while (!down_write_trylock(lock)) cond_resched(); } The original commit for this is 67ec1072b053c15564e6090ab30127895dc77a89 What we're suspecting is that a normal thread (SCHED_OTHER) has a reader lock and a real-time thread using SCHED_RR or SCHED_FIFO is trying to take the writer lock. If both threads are pinned to the same CPU for some reason then the reader thread will never get scheduled (because the real-time writer thread is still runnable), and we will never make progress. Does this sound right? What can we do to fix this? Thanks, Rob.

2 2

[alsa-devel] [PATCH alsa-lib] ioplug: Fix comment in struct snd_pcm_ioplug
by Andre Guedes 02 Oct '18

02 Oct '18

This patch fixes the comment about 'pcm' field in 'struct snd_pcm_ioplug' which wrongly refers to snd_pcm_extplug_create(). Signed-off-by: Andre Guedes <andre.guedes(a)intel.com> --- include/pcm_ioplug.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/pcm_ioplug.h b/include/pcm_ioplug.h index b16fc8b8..81ac8613 100644 --- a/include/pcm_ioplug.h +++ b/include/pcm_ioplug.h @@ -105,7 +105,7 @@ struct snd_pcm_ioplug { */ void *private_data; /** - * PCM handle filled by #snd_pcm_extplug_create() + * PCM handle filled by #snd_pcm_ioplug_create() */ snd_pcm_t *pcm; -- 2.14.4

3 2

[alsa-devel] [PATCH - Multiple plugins 0/4] Fix leaks on multiple plugins
by Andre Guedes 02 Oct '18

02 Oct '18

Hi all, While I was working on AAF plugin RFC v2 series [1], I spotted several leaks in some plugins when handling *_hw_constraint() error cases. This series fixes these issues. Regards, Andre [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2018-September/140290.… Andre Guedes (4): a52: Fix leaks when a52_set_hw_constraint() fails jack: Fix leaks when jack_set_hw_constraint() fails oss: Fix leaks when oss_hw_constraint() fails usb_stream: Fix leaks when us_set_hw_constraint() fails a52/pcm_a52.c | 2 +- jack/pcm_jack.c | 1 + oss/pcm_oss.c | 2 +- usb_stream/pcm_usb_stream.c | 1 + 4 files changed, 4 insertions(+), 2 deletions(-) -- 2.14.4

3 6

[alsa-devel] [PATCH] ALSA: firewire-lib: add PCM rules to obsolete PCM constraints based on LCM of SYT_INTERVAL
by Takashi Sakamoto 02 Oct '18

02 Oct '18

In blocking mode of IEC 61883-1/6, when one isochronous packet includes data for events, the data is for the same number of events as SYT_INTERVAL decided according to sampling transmission frequency (SFC). IEC 61883-1/6 engine of ALSA firewire stack applies constraints of period and buffer size of PCM intermediate buffer of PCM substream. At present, this constraint is designed to round the size up/down to 32 frames. This value comes from the least common multiple (LCM) of SYT_INTERVAL. Although this looks to work well, in lower sampling rate, applications are not allowed to set size of period quite near period time constraint (at present 5 msec per period). This commit adds PCM rules for period/buffer size and rate to obsoletes the constraints based on LCM. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-stream.c | 78 +++++++++++++++++++++++++++++++---- 1 file changed, 71 insertions(+), 7 deletions(-) diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c index cb9acfe60f6a..fcd965f1d69e 100644 --- a/sound/firewire/amdtp-stream.c +++ b/sound/firewire/amdtp-stream.c @@ -140,6 +140,59 @@ const unsigned int amdtp_rate_table[CIP_SFC_COUNT] = { }; EXPORT_SYMBOL(amdtp_rate_table); +static int apply_constraint_to_size(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *s = hw_param_interval(params, rule->var); + const struct snd_interval *r = + hw_param_interval_c(params, SNDRV_PCM_HW_PARAM_RATE); + struct snd_interval t = { + .min = s->min, .max = s->max, .integer = 1, + }; + int i; + + for (i = 0; i < CIP_SFC_COUNT; ++i) { + unsigned int rate = amdtp_rate_table[i]; + unsigned int step = amdtp_syt_intervals[i]; + + if (!snd_interval_test(r, rate)) + continue; + + t.min = roundup(t.min, step); + t.max = rounddown(t.max, step); + } + + if (snd_interval_checkempty(&t)) + return -EINVAL; + + return snd_interval_refine(s, &t); +} + +static int apply_constraint_to_rate(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *r = + hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE); + const struct snd_interval *s = hw_param_interval_c(params, rule->deps[0]); + struct snd_interval t = { + .min = UINT_MAX, .max = 0, .integer = 1, + }; + int i; + + for (i = 0; i < CIP_SFC_COUNT; ++i) { + unsigned int step = amdtp_syt_intervals[i]; + unsigned int rate = amdtp_rate_table[i]; + + if (s->min % step || s->max % step) + continue; + + t.min = min(t.min, rate); + t.max = max(t.max, rate); + } + + return snd_interval_refine(r, &t); +} + /** * amdtp_stream_add_pcm_hw_constraints - add hw constraints for PCM substream * @s: the AMDTP stream, which must be initialized. @@ -194,16 +247,27 @@ int amdtp_stream_add_pcm_hw_constraints(struct amdtp_stream *s, * number equals to SYT_INTERVAL. So the number is 8, 16 or 32, * depending on its sampling rate. For accurate period interrupt, it's * preferrable to align period/buffer sizes to current SYT_INTERVAL. - * - * TODO: These constraints can be improved with proper rules. - * Currently apply LCM of SYT_INTERVALs. */ - err = snd_pcm_hw_constraint_step(runtime, 0, - SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 32); + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_SIZE, + apply_constraint_to_size, NULL, + SNDRV_PCM_HW_PARAM_RATE, -1); + if (err < 0) + goto end; + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, + apply_constraint_to_rate, NULL, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, -1); + if (err < 0) + goto end; + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, + apply_constraint_to_size, NULL, + SNDRV_PCM_HW_PARAM_RATE, -1); + if (err < 0) + goto end; + err = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, + apply_constraint_to_rate, NULL, + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1); if (err < 0) goto end; - err = snd_pcm_hw_constraint_step(runtime, 0, - SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 32); end: return err; } -- 2.17.1

2 1

[alsa-devel] [PATCH][alsa-lib] timer: fix wrong comment to refer to 'SNDRV_TIMER_PSFLG_*'
by Takashi Sakamoto 02 Oct '18

02 Oct '18

ALSA timer core has a comment referring to 'SNDRV_MIXER_PSFLG_*' in a definition of 'struct snd_timer_params' of UAPI header. I can see this in initial state of ALSA timer core, at least in 'alsa-driver-0.4.0.tar.gz'. This commit fixes the comment. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- include/sound/asound.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/sound/asound.h b/include/sound/asound.h index 6041cab2..4d35c84d 100644 --- a/include/sound/asound.h +++ b/include/sound/asound.h @@ -750,7 +750,7 @@ struct snd_timer_info { #define SNDRV_TIMER_PSFLG_EARLY_EVENT (1<<2) /* write early event to the poll queue */ struct snd_timer_params { - unsigned int flags; /* flags - SNDRV_MIXER_PSFLG_* */ + unsigned int flags; /* flags - SNDRV_TIMER_PSFLG_* */ unsigned int ticks; /* requested resolution in ticks */ unsigned int queue_size; /* total size of queue (32-1024) */ unsigned int reserved0; /* reserved, was: failure locations */ -- 2.17.1

2 1