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

[alsa-devel] [PATCH] ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages
by Takashi Sakamoto 01 Jul '19

01 Jul '19

In IEC 61883-6, 8 MIDI data streams are multiplexed into single MIDI conformant data channel. The index of stream is calculated by modulo 8 of the value of data block counter. In fireworks, the value of data block counter in CIP header has a quirk with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA IEC 61883-1/6 packet streaming engine to miss detection of MIDI messages. This commit fixes the miss detection to modify the value of data block counter for the modulo calculation. For maintainers, this bug exists since a commit 18f5ed365d3f ("ALSA: fireworks/firewire-lib: add support for recent firmware quirk") in Linux kernel v4.2. There're many changes since the commit. This fix can be backported to Linux kernel v4.4 or later. I tagged a base commit to the backport for your convenience. Besides, my work for Linux kernel v5.3 brings heavy code refactoring and some structure members are renamed in 'sound/firewire/amdtp-stream.h'. The content of this patch brings conflict when merging -rc tree with this patch to the latest tree. I request maintainers to solve the conflict by replacing 'tx_first_dbc' with 'ctx_data.tx.first_dbc'. Fixes: df075feefbd3 ("ALSA: firewire-lib: complete AM824 data block processing layer") Cc: <stable(a)vger.kernel.org> # v4.4+ Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-am824.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/firewire/amdtp-am824.c b/sound/firewire/amdtp-am824.c index 4210e5c6262e..4d677fcb4fc2 100644 --- a/sound/firewire/amdtp-am824.c +++ b/sound/firewire/amdtp-am824.c @@ -321,6 +321,7 @@ static void read_midi_messages(struct amdtp_stream *s, u8 *b; for (f = 0; f < frames; f++) { + port = (8 - s->tx_first_dbc + s->data_block_counter + f) % 8; port = (s->data_block_counter + f) % 8; b = (u8 *)&buffer[p->midi_position]; -- 2.20.1

2 4

[alsa-devel] ALSA repos
by Daniel Baluta 01 Jul '19

01 Jul '19

Hi Jaroslav, What are trying to understand where are the official ALSA project repos. We found: - Github: https://github.com/alsa-project and - alsa-project.org: https://git.alsa-project.org/ Which one should we use for our daily builds? For example we have been using alsa-project.org repo for tinycompress. But in the last few days git clone didn't work! Now it seems to be back online. Also, we are using Yocto poky recipes: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-multimedia/alsa… which use pre-build archives from: https://www.alsa-project.org/files/pub/ So, any clarifications on the release deliverables for ALSA project would be highly appreciated. thanks, Daniel.

2 1

[alsa-devel] [PATCH] ALSA: hda: Fix a headphone detection issue when using SOF
by Rander Wang 01 Jul '19

01 Jul '19

To save power, the hda hdmi driver in ASoC invokes snd_hdac_ext_bus_link_put to disable CORB/RIRB buffers DMA if there is no user of bus and invokes snd_hdac_ext_bus_link_get to set up CORB/RIRB buffers when it is used. Unsolicited responses is disabled in snd_hdac_bus_stop_cmd_io called by snd_hdac_ext_bus_link_put , but it is not enabled in snd_hdac_bus_init_cmd_io called by snd_hdac_ext_bus_link_get. So for put-get sequence, Unsolicited responses is disabled and headphone can't be detected by hda codecs. Now unsolicited responses is only enabled in snd_hdac_bus_reset_link which resets controller. The function is only called for setup of controller. This patch enables Unsolicited responses after RIRB is initialized in snd_hdac_bus_init_cmd_io which works together with snd_hdac_bus_reset_link to set up controller. Tested legacy hda driver and SOF driver on intel whiskeylake. Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Rander Wang <rander.wang(a)linux.intel.com> --- sound/hda/hdac_controller.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c index d6a91429c058..c24fc8d266a9 100644 --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -78,6 +78,8 @@ void snd_hdac_bus_init_cmd_io(struct hdac_bus *bus) snd_hdac_chip_writew(bus, RINTCNT, 1); /* enable rirb dma and response irq */ snd_hdac_chip_writeb(bus, RIRBCTL, AZX_RBCTL_DMA_EN | AZX_RBCTL_IRQ_EN); + /* Accept unsolicited responses */ + snd_hdac_chip_updatel(bus, GCTL, AZX_GCTL_UNSOL, AZX_GCTL_UNSOL); spin_unlock_irq(&bus->reg_lock); } EXPORT_SYMBOL_GPL(snd_hdac_bus_init_cmd_io); @@ -416,9 +418,6 @@ int snd_hdac_bus_reset_link(struct hdac_bus *bus, bool full_reset) return -EBUSY; } - /* Accept unsolicited responses */ - snd_hdac_chip_updatel(bus, GCTL, AZX_GCTL_UNSOL, AZX_GCTL_UNSOL); - /* detect codecs */ if (!bus->codec_mask) { bus->codec_mask = snd_hdac_chip_readw(bus, STATESTS); -- 2.14.1

2 1

[alsa-devel] why error return in sound/soc/codecs/pcm3168a.c::pcm3168a_set_dai_fmt ?
by Jurgen Lambrecht 01 Jul '19

01 Jul '19

Hi, When following https://bootlin.com/blog/eight-channels-audio-on-i-mx7-with-pcm3168/ I get this error (from soc_core.c): ... kernel: [ 3.059634][ T15] pcm3168a 3-0039: ASoC: Failed to set DAI format: -22 I could propose this patch (I get that printf when applying the patch) (all other errors in that file have a printf): diff --git a/sound/soc/codecs/pcm3168a.c b/sound/soc/codecs/pcm3168a.c index 08d3fe192e65..75ccbb919902 100644 --- a/sound/soc/codecs/pcm3168a.c +++ b/sound/soc/codecs/pcm3168a.c @@ -353,6 +353,7 @@ static int pcm3168a_set_dai_fmt(struct snd_soc_dai *dai, case SND_SOC_DAIFMT_NB_NF: break; default: + dev_err(component->dev, "wrong INV_MASK\n"); return -EINVAL; } But why does this code returns an error for code that has no effect? OK, it could be because SND_SOC_DAIFMT_INV_MASK must be SND_SOC_DAIFMT_NB_NF. But then Alexandre's blog contains an error, because the dac TDM sets frame-inversion in its dts (and it should not). -- Kind Regards, *Jürgen Lambrecht* R&D Associate Tel: +32 51 303045 www.televic-rail.com <https://www.televic-rail.com> Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium Company number 0825 539 581 - RPR Kortrijk

2 1

Re: [alsa-devel] [BUG] Line6 Helix / X Stomp: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 16)
by nick83ola 01 Jul '19

01 Jul '19

On Thu, 27 Jun 2019 at 17:22, Jens Verwiebe <info(a)jensverwiebe.de> wrote: > > Hi Nick > > This looks like the same hurdle i once had with Helix. > > Imho you should first try my patch to format.c and extend the > vendor/model clause to your device: > > diff --git a/sound/usb/format.c b/sound/usb/format.c > index 2c44386..1c0107d 100644 > --- a/sound/usb/format.c > +++ b/sound/usb/format.c > @@ -298,6 +298,20 @@ static int parse_audio_format_rates_v2(struct > snd_usb_audio *chip, > goto err; > } > > + /* > + * Line6 HELIX does not respond to sample rate > + * query requests. The only valid rate is 48000. > + */ > + if (chip->usb_id == USB_ID(0x0e41, 0x4244)) { > + fp->nr_rates = 1; > + fp->rate_min = 48000; > + fp->rate_max = 48000; > + fp->rates = SNDRV_PCM_RATE_48000; > + fp->rate_table = kmalloc(sizeof(int), GFP_KERNEL); > + fp->rate_table[0] = 48000; > + return 0; > + } > + > /* get the number of sample rates first by only fetching 2 bytes */ > ret = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_RANGE, > USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, > I can confirm that your patch get the device recognized in kernel 5.2 (I modfied it a bit). I'll work on this a bit and try to submit a patch to alsa to at least having the device available. Regarding the second part ( get_usb_high_speed_rate(rate + 5);) I think I have to debug it better because I don't think it can be accepted upstream. (maybe someone from the mailing list can help?) > I personally encountered still slight pops from time to time which i > "healed" with an ugly second patch: > > diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c > index c90607e..026095a 100644 > --- a/sound/usb/endpoint.c > +++ b/sound/usb/endpoint.c > @@ -878,6 +878,8 @@ int snd_usb_endpoint_set_params(struct > snd_usb_endpoint *ep, > > if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL) > ep->freqn = get_usb_full_speed_rate(rate); > + else if (USB_ID(0x0e41, 0x4244)) > + ep->freqn = get_usb_high_speed_rate(rate + 5); // ugly helix hack > else > ep->freqn = get_usb_high_speed_rate(rate); > > > I still never could get the Line6 device to really follow the > syncadaption in 16.16 format. > > I tried all kinda voodoo like endpoint redirection ( like axe fx needs ) > to no avail. Perhaps you have better ideas. > > I would be very interested in getting Line6 devices usb-compliant mode > working 100 % reliable. > > The dream would be to have all samplerates. Btw:: i have sniffed data > from Helix connected to a windows machine, > > ioreg data from helix connected to an OSX(macOS) machine and even a bit > experimented with retdec on the windows drivers ;). > > This for now, 'am just on the jump to the Hamburg Linux Group :) > > Lets stay in contact about this stuff. > > Cheers ... Jens > > > Am 27.06.19 um 09:45 schrieb nick83ola: > > Hi all, > > I just purchased an HX stomp and when I connect to linux I get the > > following error message: > > > > [ 322.404503] usb 1-6: new high-speed USB device number 13 using xhci_hcd > > [ 322.531804] usb 1-6: New USB device found, idVendor=0e41, > > idProduct=4246, bcdDevice= 2.00 > > [ 322.531806] usb 1-6: New USB device strings: Mfr=1, Product=3, > > SerialNumber=2 > > [ 322.531806] usb 1-6: Product: HX Stomp > > [ 322.531807] usb 1-6: Manufacturer: LINE 6 > > [ 322.531808] usb 1-6: SerialNumber: 3021888 > > [ 322.535789] usb 1-6: parse_audio_format_rates_v2v3(): unable to > > retrieve number of sample rates (clock 16) > > [ 322.535907] usb 1-6: parse_audio_format_rates_v2v3(): unable to > > retrieve number of sample rates (clock 16) > > > > I have some kernel development experience but not a lot with usb so > > can someone point me where to start looking? > > > > there was a previous discussion on the mailing list related to this by > > Jens Verwiebe (and other request for help). > > Here are the relevant patches/discussion > > > > https://www.spinics.net/lists/alsa-devel/msg71459.html > > https://patchwork.kernel.org/patch/10113121/ > > > > If someone can help me I have an HX stomp here and time to do some debugging. > > > > Also if someone from Line6 is listening would be helpful to have some hints. > > > > Cheers > > Nicola Lunghi > > > -- > > Jens Verwiebe

1 0

[alsa-devel] [PATCH] ALSA: xen-front: fix unintention integer overflow on left shifts
by Colin King 01 Jul '19

01 Jul '19

From: Colin Ian King <colin.king(a)canonical.com> Shifting the integer value 1 is evaluated using 32-bit arithmetic and then used in an expression that expects a 64-bit value, so there is potentially an integer overflow. Fix this by using the BIT_ULL macro to perform the shift. Addresses-Coverity: ("Unintentional integer overflow") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/xen/xen_snd_front_alsa.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/xen/xen_snd_front_alsa.c b/sound/xen/xen_snd_front_alsa.c index b14ab512c2ce..e01631959ed8 100644 --- a/sound/xen/xen_snd_front_alsa.c +++ b/sound/xen/xen_snd_front_alsa.c @@ -196,7 +196,7 @@ static u64 to_sndif_formats_mask(u64 alsa_formats) mask = 0; for (i = 0; i < ARRAY_SIZE(ALSA_SNDIF_FORMATS); i++) if (pcm_format_to_bits(ALSA_SNDIF_FORMATS[i].alsa) & alsa_formats) - mask |= 1 << ALSA_SNDIF_FORMATS[i].sndif; + mask |= BIT_ULL(ALSA_SNDIF_FORMATS[i].sndif); return mask; } @@ -208,7 +208,7 @@ static u64 to_alsa_formats_mask(u64 sndif_formats) mask = 0; for (i = 0; i < ARRAY_SIZE(ALSA_SNDIF_FORMATS); i++) - if (1 << ALSA_SNDIF_FORMATS[i].sndif & sndif_formats) + if (BIT_ULL(ALSA_SNDIF_FORMATS[i].sndif) & sndif_formats) mask |= pcm_format_to_bits(ALSA_SNDIF_FORMATS[i].alsa); return mask; -- 2.20.1

3 2