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

[alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay
by Mike Brady 01 Jan '19

01 Jan '19

When the BCM2835 audio output is used, userspace sees a jitter up to 10ms in the audio position, aka "delay" -- the number of frames that must be output before a new frame would be played. Make this a bit nicer for userspace by interpolating the position using the CPU clock. The overhead is small -- an extra ktime_get() every time a GPU message is sent -- and another call and a few calculations whenever the delay is sought from userland. At 48,000 frames per second, i.e. approximately 20 microseconds per frame, it would take a clock inaccuracy of 20 microseconds in 10 milliseconds -- 2,000 parts per million -- to result in an inaccurate estimate, whereas crystal- or resonator-based clocks typically have an inaccuracy of 10s to 100s of parts per million. Signed-off-by: Mike Brady <mikebrady(a)eircom.net> --- Changes in v2 -- remove inappropriate addition of SNDRV_PCM_INFO_BATCH flag .../vc04_services/bcm2835-audio/bcm2835-pcm.c | 20 +++++++++++++++++++ .../vc04_services/bcm2835-audio/bcm2835.h | 1 + 2 files changed, 21 insertions(+) diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c index e66da11af5cf..9053b996cada 100644 --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c @@ -74,6 +74,7 @@ void bcm2835_playback_fifo(struct bcm2835_alsa_stream *alsa_stream, atomic_set(&alsa_stream->pos, pos); alsa_stream->period_offset += bytes; + alsa_stream->interpolate_start = ktime_get(); if (alsa_stream->period_offset >= alsa_stream->period_size) { alsa_stream->period_offset %= alsa_stream->period_size; snd_pcm_period_elapsed(substream); @@ -243,6 +244,7 @@ static int snd_bcm2835_pcm_prepare(struct snd_pcm_substream *substream) atomic_set(&alsa_stream->pos, 0); alsa_stream->period_offset = 0; alsa_stream->draining = false; + alsa_stream->interpolate_start = ktime_get(); return 0; } @@ -292,6 +294,24 @@ snd_bcm2835_pcm_pointer(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; struct bcm2835_alsa_stream *alsa_stream = runtime->private_data; + ktime_t now = ktime_get(); + + /* Give userspace better delay reporting by interpolating between GPU + * notifications, assuming audio speed is close enough to the clock + * used for ktime + */ + + if ((ktime_to_ns(alsa_stream->interpolate_start)) && + (ktime_compare(alsa_stream->interpolate_start, now) < 0)) { + u64 interval = + (ktime_to_ns(ktime_sub(now, + alsa_stream->interpolate_start))); + u64 frames_output_in_interval = + div_u64((interval * runtime->rate), 1000000000); + snd_pcm_sframes_t frames_output_in_interval_sized = + -frames_output_in_interval; + runtime->delay = frames_output_in_interval_sized; + } return snd_pcm_indirect_playback_pointer(substream, &alsa_stream->pcm_indirect, diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h index e13435d1c205..595ad584243f 100644 --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835.h @@ -78,6 +78,7 @@ struct bcm2835_alsa_stream { unsigned int period_offset; unsigned int buffer_size; unsigned int period_size; + ktime_t interpolate_start; struct bcm2835_audio_instance *instance; int idx; -- 2.17.1

4 17

[alsa-devel] [PATCH 0/6] ASoC: rt5651: Various fixes and quirks
by Hans de Goede 24 Dec '18

24 Dec '18

Hi All, Here is my last (big) round of (Intel) rt5651 support updates, with these patches combined with the updated, matching UCM profiles from here: https://github.com/jwrdegoede/alsa-lib/commits/master All 7 different devices I have work 100% OOTB, without requiring any manual config or mixer setup. After this there should be no more big changes. I will submit the matching alsa-lib UCM profile changes upstream once this set is in -next (and thus I can be sure the long-names will not change due to review). Note that unfortunately my previous round of cleanup patches removed 1 input mapping (of the 3 mappings in total it removed) which is actually necessary. So this series re-introduces that 1 mapping. I did not notice this before because UCM input profile switching does not work reliably for some reason, something which I still need to investigate. This time I manually veryfied that the correct / expected mixer settings where used while testing. Regards, Hans

4 23

[alsa-devel] [PATCH v3] ASoC: AMD: Fix race condition between register access
by Agrawal, Akshu 19 Dec '18

19 Dec '18

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> --- v2: Added 2 helper functions, removed locking in ch enable/disable as they are separate registers. v3: Modified helper acp_reg_read_mod_write, moved pte locks to helper sound/soc/amd/acp-pcm-dma.c | 66 ++++++++++++++++++++++++++++++--------------- 1 file changed, 44 insertions(+), 22 deletions(-) diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c index 0ac4b5b..0d4c2eb 100644 --- a/sound/soc/amd/acp-pcm-dma.c +++ b/sound/soc/amd/acp-pcm-dma.c @@ -121,6 +121,9 @@ .periods_max = CAPTURE_MAX_NUM_PERIODS, }; +/* Lock to protect access to registers */ +static DEFINE_SPINLOCK(lock); + static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg) { return readl(acp_mmio + (reg * 4)); @@ -131,6 +134,31 @@ static void acp_reg_write(u32 val, void __iomem *acp_mmio, u32 reg) writel(val, acp_mmio + (reg * 4)); } +static void acp_reg_write_srbm_targ(void __iomem *acp_mmio, + u32 addr, u32 data) +{ + unsigned long flags; + + spin_lock_irqsave(&lock, flags); + acp_reg_write(addr, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); + acp_reg_write(data, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + spin_unlock_irqrestore(&lock, flags); +} + +static void acp_reg_read_mod_write(void __iomem *acp_mmio, u32 addr, + u32 mask, u32 value) +{ + u32 val; + unsigned long flags; + + spin_lock_irqsave(&lock, flags); + val = acp_reg_read(acp_mmio, addr); + val &= ~mask; + val |= (mask & value); + acp_reg_write(val, acp_mmio, addr); + spin_unlock_irqrestore(&lock, flags); +} + /* * Configure a given dma channel parameters - enable/disable, * number of descriptors, priority @@ -172,15 +200,12 @@ static void config_dma_descriptor_in_sram(void __iomem *acp_mmio, sram_offset = (descr_idx * sizeof(acp_dma_dscr_transfer_t)); /* program the source base address. */ - acp_reg_write(sram_offset, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); - acp_reg_write(descr_info->src, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + acp_reg_write_srbm_targ(acp_mmio, sram_offset, descr_info->src); /* program the destination base address. */ - acp_reg_write(sram_offset + 4, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); - acp_reg_write(descr_info->dest, acp_mmio, mmACP_SRBM_Targ_Idx_Data); - + acp_reg_write_srbm_targ(acp_mmio, sram_offset + 4, descr_info->dest); /* program the number of bytes to be transferred for this descriptor. */ - acp_reg_write(sram_offset + 8, acp_mmio, mmACP_SRBM_Targ_Idx_Addr); - acp_reg_write(descr_info->xfer_val, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + acp_reg_write_srbm_targ(acp_mmio, sram_offset + 8, + descr_info->xfer_val); } static void pre_config_reset(void __iomem *acp_mmio, u16 ch_num) @@ -311,24 +336,22 @@ static void acp_pte_config(void __iomem *acp_mmio, struct page *pg, u32 offset; offset = ACP_DAGB_GRP_SRBM_SRAM_BASE_OFFSET + (pte_offset * 8); + for (page_idx = 0; page_idx < (num_of_pages); page_idx++) { /* Load the low address of page int ACP SRAM through SRBM */ - acp_reg_write((offset + (page_idx * 8)), - acp_mmio, mmACP_SRBM_Targ_Idx_Addr); addr = page_to_phys(pg); low = lower_32_bits(addr); high = upper_32_bits(addr); - acp_reg_write(low, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + acp_reg_write_srbm_targ(acp_mmio, (offset + (page_idx * 8)), + low); /* Load the High address of page int ACP SRAM through SRBM */ - acp_reg_write((offset + (page_idx * 8) + 4), - acp_mmio, mmACP_SRBM_Targ_Idx_Addr); - /* page enable in ACP */ high |= BIT(31); - acp_reg_write(high, acp_mmio, mmACP_SRBM_Targ_Idx_Data); + acp_reg_write_srbm_targ(acp_mmio, (offset + (page_idx * 8) + 4), + high); /* Move to next physically contiguos page */ pg++; @@ -870,29 +893,28 @@ static int acp_dma_hw_params(struct snd_pcm_substream *substream, } } if (adata->asic_type == CHIP_STONEY) { - val = acp_reg_read(adata->acp_mmio, - mmACP_I2S_16BIT_RESOLUTION_EN); if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { switch (rtd->i2s_instance) { case I2S_BT_INSTANCE: - val |= ACP_I2S_BT_16BIT_RESOLUTION_EN; + val = ACP_I2S_BT_16BIT_RESOLUTION_EN; break; case I2S_SP_INSTANCE: default: - val |= ACP_I2S_SP_16BIT_RESOLUTION_EN; + val = ACP_I2S_SP_16BIT_RESOLUTION_EN; } } else { switch (rtd->i2s_instance) { case I2S_BT_INSTANCE: - val |= ACP_I2S_BT_16BIT_RESOLUTION_EN; + val = ACP_I2S_BT_16BIT_RESOLUTION_EN; break; case I2S_SP_INSTANCE: default: - val |= ACP_I2S_MIC_16BIT_RESOLUTION_EN; + val = ACP_I2S_MIC_16BIT_RESOLUTION_EN; } } - acp_reg_write(val, adata->acp_mmio, - mmACP_I2S_16BIT_RESOLUTION_EN); + acp_reg_read_mod_write(adata->acp_mmio, + mmACP_I2S_16BIT_RESOLUTION_EN, + val, val); } if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { -- 1.9.1

2 2

[alsa-devel] [GIT PULL] Additional firmware files for CA0132 HD-audio codec
by Connor McAdams 14 Dec '18

14 Dec '18

The following changes since commit c6b6265d718d118e28e1ce8f91769aa886b54c94: Merge tag 'iwlwifi-fw-2018-10-03' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware (2018-10-08 09:23:53 -0400) are available in the git repository at: git@github.com:Conmanx360/linux-firmware.git for you to fetch changes up to cd8899323352e772c5989230f35b1c494e0ab196: linux-firmware: Add new firmware for Creative CA0132 HD-Audio Codec (2018-10-09 14:41:12 -0400) ---------------------------------------------------------------- These are additional firmware files for CA0132 based sound cards. Creative has given me permission through email to send these to the linux-firmware repository under the same license as the previous ca0132 firmware. I asked my contact if they would sign-off on it, but they said to go ahead and submit it and that if there was any issue to contact them. If you need to contact them, or if there's more info needed, let me know and I can get see what I can do. ---------------------------------------------------------------- Connor McAdams (1): linux-firmware: Add new firmware for Creative CA0132 HD-Audio Codec WHENCE | 2 ++ ctefx-desktop.bin | Bin 0 -> 655856 bytes ctefx-r3di.bin | Bin 0 -> 655816 bytes 3 files changed, 2 insertions(+) create mode 100644 ctefx-desktop.bin create mode 100644 ctefx-r3di.bin

3 6

[alsa-devel] remove bogus GFP_DMA32 flags for dma allocations
by Christoph Hellwig 05 Dec '18

05 Dec '18

dma_alloc_* internally selects the zone to allocate from based on the DMA mask. Remove all explicit uses of GFP_DMA32 with dma_alloc_*.

6 29

[alsa-devel] User-friendly dynamic HDA pin reconfiguration
by Daniel Drake 29 Nov '18

29 Nov '18

Hi, We are working with a new consumer All-in-One platform with HDA audio (Realtek codec). Upon plugging in an audio device into one of the audio jacks, under Windows, a prompt appears which says: Which device did you plug in? And you can select from several options: Mic In / Headphone / Speaker Out Screenshot: https://imgur.com/a/mrUolHN The system vendor is asking if we can implement the same under Linux. At first glance, this sounds quite similar to what happens on other models when you plug in a headset under GNOME: a dialog pops up asking if you connected a mic, headphones, or a headset. Under the surface, such headset jacks seems to correspond to 2 separate HDA pins (one input and one output) and this dialog seems to manage which streams are enabled or muted. However, this case is different. We have experimented, and the jack corresponds to just a single HDA pin. We can manually quirk or retask this pin to be an input or an output and it works in the direction that we choose. But that's a far cry from having a nice GUI that automatically comes up asking the user how the pin should be configured. Is there any current solution or work in progress with the goal of offering this functionality? If not, brainstorming, possible solutions could include: 1. Taking the hdajackretask idea but making it user-accessible and user-friendly (currently it goes through debugfs and must be done by root). This would require the creation of a new kernel interface to expose pin reconfiguration in a nicer way, which would have to be plumbed through pulseaudio and GNOME. 2. Could ALSA ignore the pin config here and provide both input and output streams for this pin? Then pulseaudio + GUI could pick which one to use - similar to the existing Headset dialog. This would still require some work on pulseaudio and the corresponding UI, but it might be a less invasive project. Thanks, Daniel

2 2

[alsa-devel] [PATCH v2 01/13] conf/ucm: bytcr-rt5645: Use the generic bytcr/PlatformEnableSeq.conf
by Hans de Goede 28 Nov '18

28 Nov '18

Use the generic Intel SSP bytcr/PlatformEnableSeq.conf file, it is identical to all the cset statements this commit removes. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- src/conf/ucm/chtrt5645/HiFi.conf | 116 +------------------------------ 1 file changed, 1 insertion(+), 115 deletions(-) diff --git a/src/conf/ucm/chtrt5645/HiFi.conf b/src/conf/ucm/chtrt5645/HiFi.conf index e81866cf..d993f6ae 100644 --- a/src/conf/ucm/chtrt5645/HiFi.conf +++ b/src/conf/ucm/chtrt5645/HiFi.conf @@ -11,121 +11,7 @@ SectionVerb { EnableSequence [ cdev "hw:chtrt5645" - # media mixer settings - # compress - cset "name='media0_in Gain 0 Switch' on" - cset "name='media0_in Gain 0 Volume' 0" - - # normal - cset "name='media1_in Gain 0 Switch' on" - cset "name='media1_in Gain 0 Volume' 0" - # swm loopback - cset "name='media2_in Gain 0 Switch' off" - cset "name='media2_in Gain 0 Volume' 0%" - # deep buffer - cset "name='media3_in Gain 0 Switch' on" - cset "name='media3_in Gain 0 Volume' 0" - - cset "name='media0_out mix 0 media0_in Switch' on" - cset "name='media0_out mix 0 media1_in Switch' on" - cset "name='media0_out mix 0 media2_in Switch' off" - cset "name='media0_out mix 0 media3_in Switch' on" - - cset "name='media1_out mix 0 media0_in Switch' off" - cset "name='media1_out mix 0 media1_in Switch' off" - cset "name='media1_out mix 0 media2_in Switch' off" - cset "name='media1_out mix 0 media3_in Switch' off" - - cset "name='pcm0_in Gain 0 Switch' on" - cset "name='pcm0_in Gain 0 Volume' 0" - - cset "name='pcm1_in Gain 0 Switch' off" - cset "name='pcm1_in Gain 0 Volume' 0%" - - # codec0_out settings (used if ssp2 is connected to aif1) - cset "name='codec_out0 mix 0 codec_in0 Switch' off" - cset "name='codec_out0 mix 0 codec_in1 Switch' off" - cset "name='codec_out0 mix 0 media_loop1_in Switch' off" - cset "name='codec_out0 mix 0 media_loop2_in Switch' off" - cset "name='codec_out0 mix 0 pcm0_in Switch' on" - cset "name='codec_out0 mix 0 pcm1_in Switch' off" - cset "name='codec_out0 mix 0 sprot_loop_in Switch' off" - cset "name='codec_out0 Gain 0 Switch' on" - cset "name='codec_out0 Gain 0 Volume' 0" - - # modem_out settings (used if ssp0 is connected to aif2) - cset "name='modem_out mix 0 codec_in0 Switch' off" - cset "name='modem_out mix 0 codec_in1 Switch' off" - cset "name='modem_out mix 0 media_loop1_in Switch' off" - cset "name='modem_out mix 0 media_loop2_in Switch' off" - cset "name='modem_out mix 0 pcm0_in Switch' on" - cset "name='modem_out mix 0 pcm1_in Switch' off" - cset "name='modem_out mix 0 sprot_loop_in Switch' off" - cset "name='modem_out Gain 0 Switch' on" - cset "name='modem_out Gain 0 Volume' 0" - - # input settings - # pcm1_out settings - - # input used when SSP2 is connected - cset "name='codec_in0 Gain 0 Switch' on" - cset "name='codec_in0 Gain 0 Volume' 0" - - # input used when SSP0 is connected - cset "name='modem_in Gain 0 Switch' on" - cset "name='modem_in Gain 0 Volume' 0" - - cset "name='pcm1_out mix 0 codec_in0 Switch' on" - cset "name='pcm1_out mix 0 modem_in Switch' on" - cset "name='pcm1_out mix 0 codec_in1 Switch' off" - cset "name='pcm1_out mix 0 media_loop1_in Switch' off" - cset "name='pcm1_out mix 0 media_loop2_in Switch' off" - cset "name='pcm1_out mix 0 pcm0_in Switch' off" - cset "name='pcm1_out mix 0 pcm1_in Switch' off" - cset "name='pcm1_out mix 0 sprot_loop_in Switch' off" - - cset "name='pcm1_out Gain 0 Switch' on" - cset "name='pcm1_out Gain 0 Volume' 0" - - # disable codec_out1 - cset "name='codec_out1 mix 0 codec_in0 Switch' off" - cset "name='codec_out1 mix 0 codec_in1 Switch' off" - cset "name='codec_out1 mix 0 media_loop1_in Switch' off" - cset "name='codec_out1 mix 0 media_loop2_in Switch' off" - cset "name='codec_out1 mix 0 pcm0_in Switch' off" - cset "name='codec_out1 mix 0 pcm1_in Switch' off" - cset "name='codec_out1 mix 0 sprot_loop_in Switch' off" - cset "name='codec_out1 Gain 0 Switch' off" - cset "name='codec_out1 Gain 0 Volume' 0%" - - # disable codec_in1 - cset "name='codec_in1 Gain 0 Switch' off" - cset "name='codec_in1 Gain 0 Volume' 0%" - - # disable all loops - cset "name='media_loop1_out mix 0 codec_in0 Switch' off" - cset "name='media_loop1_out mix 0 codec_in1 Switch' off" - cset "name='media_loop1_out mix 0 media_loop1_in Switch' off" - cset "name='media_loop1_out mix 0 media_loop2_in Switch' off" - cset "name='media_loop1_out mix 0 pcm0_in Switch' off" - cset "name='media_loop1_out mix 0 pcm1_in Switch' off" - cset "name='media_loop1_out mix 0 sprot_loop_in Switch' off" - - cset "name='media_loop2_out mix 0 codec_in0 Switch' off" - cset "name='media_loop2_out mix 0 codec_in1 Switch' off" - cset "name='media_loop2_out mix 0 media_loop1_in Switch' off" - cset "name='media_loop2_out mix 0 media_loop2_in Switch' off" - cset "name='media_loop2_out mix 0 pcm0_in Switch' off" - cset "name='media_loop2_out mix 0 pcm1_in Switch' off" - cset "name='media_loop2_out mix 0 sprot_loop_in Switch' off" - - cset "name='sprot_loop_out mix 0 codec_in0 Switch' off" - cset "name='sprot_loop_out mix 0 codec_in1 Switch' off" - cset "name='sprot_loop_out mix 0 media_loop1_in Switch' off" - cset "name='sprot_loop_out mix 0 media_loop2_in Switch' off" - cset "name='sprot_loop_out mix 0 pcm0_in Switch' off" - cset "name='sprot_loop_out mix 0 pcm1_in Switch' off" - cset "name='sprot_loop_out mix 0 sprot_loop_in Switch' off" + <bytcr/PlatformEnableSeq.conf> # Output Configuration cset "name='DAC1 L Mux' IF1 DAC" -- 2.18.0

6 30

Re: [alsa-devel] CS8409 Macbook Pro 2016 2017
by Takashi Iwai 27 Nov '18

27 Nov '18

Please don't drop Cc to ML. Also avoid top-posting. On Sat, 04 Aug 2018 19:02:53 +0200, David Ulricht wrote: > > How can I do that ? > I tried verifying if /proc/asound/card0/codec#0 changes when i put > handphone jack in and out with "diff ver1 ver2" and it is exactly the same. Just do for each bit as you tried for GPIO output. In this case, the direction bit should be different (set 0), and you need to read. > > One strange thing I note is hda-jack-retask.fw contains: > [pincfg] > 0x24 0x90100080 > 0x25 0x90100082 > I have 0x90100080 for 0x24 but in /proc/asound/card0/codec#0 : > Node 0x24 [Pin Complex] wcaps 0x400101: Stereo > Pincap 0x00000010: OUT > Pin Default 0x90100110: [Fixed] Speaker at Int N/A > Conn = Unknown, Color = Unknown > DefAssociation = 0x1, Sequence = 0x0 > Misc = NO_PRESENCE > Pin-ctls: 0x40: OUT > Connection: 1 > 0x02 > > Shouldn't "Pin Default 0x90100110" be 0x90100080 after applying the patch ? No, the codec config value itself won't change, the driver uses the given value only internally. Takashi > I can see that Applying patch firmware 'hda-jack-retask.fw' is before > hdaudioC0D0: autoconfig for Generic: line_outs=2 (0x24/0x25/0x0/0x0/0x0) > type:speaker > in dmesg and this worries me, maybe the pins are overriden by generic > cirrus logic ? > > > On Sat, Aug 4, 2018 at 7:26 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > On Sat, 04 Aug 2018 17:44:59 +0200, > > David Ulricht wrote: > > > > > > I used the following script running as root to verify the 8 GPIOs while > > > playing long youtube video, > > > I have running pulseaudio meanwhile and not restarting it, i think its > > okay > > > like that people on the ubuntu forums say that after using > > > hda-verb and setting a gpio active immediately sound appears, so i guess > > > there is no need to restart pulseaudio. > > > I have done the same test with headphones in. > > > No sound in both scenarios, no input no output detected (i'm watching > > > pavucontrol for input detection). > > > > This codec is fairly unique and doesn't provide the standard jack > > detection on each pin. Maybe it's via either GPIO or any other > > method. You can try to read GPIO pins (set as input) to see whether > > any of them corresponds to the jack detection, for example. > > > > > > Takashi > > > > > > > > #!/usr/bin/env python3 > > > import os,time > > > for x in range(0,256): > > > mhex=("0x%0.2X" % x) > > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK "+mhex) > > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION "+mhex) > > > os.system("hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA "+mhex) > > > time.sleep(3) > > > > > > Meanwhile script is running I'm watching /proc/asound/card0/codec#0 and > > > IO[0-7] changes its configuration, > > > in comparison Joel Krahemann in his scripts is changing the hex right > > after > > > /dev/snd/hwC0D0 (0x01) e.g. i dont think he is modifiying the GPIOs > > > correctly. > > > > > > I found the following post: > > > https://forum.manjaro.org/t/sound-not-working-on-a-2017- > > imac-27-5k-retina/43638 > > > According to https://bugzilla.kernel.org/show_bug.cgi?id=195671 iMac27 > > has > > > a similar soundcard. > > > How can i setup with command line or any other utility: > > > """select “off” in the top menu that propose to setup the Digital > > > Surround""" > > > this is some setting in xfce4-mixer package which is not available for > > > ubuntu since 2 LTS versions behind. I tried current Manjaro and couldn't > > > find this setting in audio mixer of xfce4 either. > > > > > > On Sat, Aug 4, 2018 at 9:48 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > > > > > On Sat, 04 Aug 2018 04:07:43 +0200, > > > > David Ulricht wrote: > > > > > > > > > > Hello, > > > > > > > > > > Macbook pro models containing CS8409 for sure are: > > > > > MBP131 MBP141.I own MBP 14,1 e.g. 2017 model. > > > > > > > > > > I'm attaching working sound configuration from Windows 10 registry > > (note > > > > > that the cs420x might need to be ignored or might be important i > > don't > > > > > really know). I believe what is really used is in the > > PinConfigOverride > > > > > section. > > > > > > > > Comparing between BIOS default (init_pin_cfg in alsa-info.sh output) > > > > and your override (user_pin_cfg), there aren't so many changes. > > > > All changes are pretty minor, and I guess it won't influence on the > > > > driver behavior. > > > > > > > > > Interesting thing to note is that sound in MacOS is much louder than > > > > > Bootcamp Windows, would be nice to hear how loud is on linux. > > > > > > > > This is possibly with some vendor-specific GPIO or COEF verbs. > > > > Or it's some direct I2C control. The INI file mentions it. > > > > And that's above HD-audio driver's responsibility. > > > > > > > > > I did convert PinConfigOverride HEX strings to [pincfg] format in the > > > > > attached hda-jack-retask.fw thanks to Takashi's guidance. > > > > > > > > > > I'm attaching also alsamixer ASCII. Only PCM, no Master ? > > > > > > > > It's because the codec chip has no output amplifier at all. > > > > So there can be neither output volume nor mute control on this chip. > > > > > > > > > What I have tried is execute: > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x@@ > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x@@ > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x@@ > > > > > putting @@ from 0x00 to 0x50 > > > > > > > > There are eight GPIOs, so you'd need to test each bit, i.e. 0x01, > > > > 0x02, 0x04, 0x08, ... 0x80. > > > > > > > > And how is the current situation? You can't play *and* record > > > > anything from any inputs / outputs? > > > > > > > > > > > > Takashi > > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] > > > > > > [2 <text/html; UTF-8 (quoted-printable)>] >

3 12

[alsa-devel] [PATCH 1/2] ASoC: max9892x: Add documentation for reset-gpio support
by Cheng-Yi Chiang 20 Nov '18

20 Nov '18

max98927 codec driver will support reset-gpio binding so it can toggle reset line in its probe function. Signed-off-by: Cheng-Yi Chiang <cychiang(a)chromium.org> --- Documentation/devicetree/bindings/sound/max9892x.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt index f6171591ddc61..8bf30483eedcd 100644 --- a/Documentation/devicetree/bindings/sound/max9892x.txt +++ b/Documentation/devicetree/bindings/sound/max9892x.txt @@ -29,6 +29,8 @@ Required properties: Range : 0 (off), 1 (on), Default : 0 - reg : the I2C address of the device for I2C + - reset-gpio: reset gpio the chip is connected to. This is supported + on max98927. Example: @@ -38,4 +40,5 @@ codec: max98927@3a { imon-slot-no = <1>; interleave-mode = <0>; reg = <0x3a>; + reset-gpio = <&tlmm 75 GPIO_ACTIVE_LOW>; }; -- 2.16.4

6 13

Re: [alsa-devel] Controlling the Tascam FW-1884
by Takashi Sakamoto 16 Nov '18

16 Nov '18

Hi Scott, (C.Ced to alsa-devel, ffado-devel) On Sep 7 2018 23:01, Scott Bahling wrote: > I recently got my hands on a FW-1884 and would like to get it working in > Linux. I'm mostly interested in using the control interface which should > support several midi control interface protocols like Mackie Control or > Mackie HUI. From the user manual it appears that the host computer needs to > set the registers on the FW-1884 to switch modes (they reference Windows > applications). > > I see that you have recently been working on user space support asynchronous > commands to such devices. The hinawa_utils code has some beginnings of > support for setting options on the Tascam devices and I have just started > playing with that. Thanks for your suggestion. At present, the most of features on control surface of FW-1884 are not available, especially for fader, knob and start/stop buttons. In data transmission between system and devices on IEEE 1394 bus, both of asynchronous transactions and isochronous packet streams are available. In a case of TASCAM FireWire series, messages via MIDI physical interface is bypassed to asynchronous transaction, while messages generated on control surface are bypassed to isochronous packets, multiplexed with PCM frames. When enabling multiplexing messages to isochronous packet, demultiplexer should be implemented to ALSA firewire-tascam driver, but not yet. You can see my initial RFC in alsa-devel[1]. This patch enables userspace applications to perform the demultiplexing, however this idea easily brings cache-coherency problems due to page mapping between kernel/userspace and impossible to be applied. We need to investigate another idea to achieve the demultiplexing in kernel land. As another option, according to page 26 in 'TASCAM FW-1884 Owner's Manual', when programming Keys to port 1-4, system could receive MIDI messages from control surface of FW-1884. However, I've not investigated it. > How are you determining the registers and flags? Do you have documentation, > or are you reverse engineering? Do you know the registers and flags for > setting the control protocol? > > If you have any hints on how figure out the proper registers and flags I'm > happy to contribute to the work you have started and help support more > functions of the FW-1884. User manuals are documents to which we can refer. The most vendors licenses their drivers/software with EULA and in most cases it can't allow users to binary-based reverse engineering. All of my work are done with external protocol analyzer unit on IEEE 1394 bus. When working to implement drivers, I read/classified/parsed content of many packets sniffed by the analyzer. An initial idea of libhinawa/hinawa-utils is to assist this my work. I heard FFADO developers uses some ways for this type of work: - Usage of host controller of TI PCILynx and driver module (nosy.ko) - Windows application; bushound[2] However, this type of work takes you long time, so I don't necessarily recommend you. It's 2018 and I think you can find alternative control surfaces on USB. If you take long time to make devices available on GNU/Linux, it's better to select devices on 'live' buses instead of 'legacy' buses such as IEEE 1394 bus, IMO. In a case of USB, wireshark with usbcap is the easiest way for us to sniff packets on Windows. [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094817.html [2] http://perisoft.net/bushound/ Regards Takashi Sakamoto

2 21