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

[alsa-devel] [PATCH 0/2] pcm_file write file assert case handling
by Adam Miartus 11 Jun '19

11 Jun '19

patched possible case where failed file write can cause assert in pcm_file plugin, by reporting error EPIPE and printing debug message. reporting an error with debug hint message is preferred to assert, user may have a way to recover in upper API level. providing a debug message makes it easier to debug the issue from logs. previously, reaching assert did not provide useful message to API level user. Adam Miartus (2): pcm_file: do not disrupt playback on output file write fail pcm_file: report write output file error to api user src/pcm/pcm_file.c | 63 +++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 46 insertions(+), 17 deletions(-) -- 2.7.4

4 5

[alsa-devel] [PATCH 00/12] ALSA: firewire-digi00x/dice: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks
by Takashi Sakamoto 11 Jun '19

11 Jun '19

Hi, This patchset is a part of series of patches for all of drivers in ALSA firewire stack to reserve/release isochronous resources in pcm.hw_params/hw_free callbacks. In current implementation, the resources are reserved at the same time to start packet streaming, and released at the same time to stop packet streaming. However, once allocated, the resources are available independent of lifetime of each of packet streaming. The isochronous resources are the resources of IEEE 1394 bus. On the other side of view, it's a kind of resources of hardware to maintain the bus (isochronous resource manager). For this kind of reservation and release, hw_params and hw_free operations are suitable in ALSA PCM interface. Ideally, the operation to reserve/release isochronous resource should be separated from the operation to start/stop packet streaming. However, IEEE 1394 bus has reset event. Once reset occurs, isochronous resource manager releases allocated resources. The resources should be reallocated by requesters themselves. For this reason, in this patchset, bus generation is checked before starting packet streaming. If generation is updated, reallocation is requested to isochronous resource manager, then packet streaming starts. Takashi Sakamoto (12): ALSA: firewire-digi00x: refactoring to move timing of registration for isochronous channel ALSA: firewire-digi00x: code refactoring to finish streaming session ALSA: firewire-digi00x: simplify error path to begin streaming session ALSA: firewire-digi00x: code refactoring to keep isochronous resources ALSA: firewire-digi00x: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks ALSA: firewire-digi00x: update isochronous resources when starting packet streaming after bus-reset ALSA: firewire-digi00x: code refactoring for pcm.hw_params/hw_free callbacks ALSA: dice: code refactoring to stop packet streaming ALSA: dice: code refactoring to keep isochronous resources ALSA: dice: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks ALSA: dice: update isochronous resources when starting packet streaming after bus-reset ALSA: dice: code refactoring for pcm.hw_params/hw_free callbacks sound/firewire/dice/dice-midi.c | 10 +- sound/firewire/dice/dice-pcm.c | 62 ++--- sound/firewire/dice/dice-stream.c | 350 +++++++++++++----------- sound/firewire/dice/dice.h | 4 +- sound/firewire/digi00x/digi00x-midi.c | 10 +- sound/firewire/digi00x/digi00x-pcm.c | 65 ++--- sound/firewire/digi00x/digi00x-stream.c | 189 ++++++------- sound/firewire/digi00x/digi00x.h | 4 +- 8 files changed, 342 insertions(+), 352 deletions(-) -- 2.20.1

2 13

[alsa-devel] [PATCH] ALSA: usb-audio: Enable .product_name override for Emagic, Unitor 8.
by Stefan Sauer 11 Jun '19

11 Jun '19

>From a41303935608e9a98653d4dff1e10baf1ce07e05 Mon Sep 17 00:00:00 2001 From: Stefan Sauer <ensonic(a)google.com> Date: Mon, 10 Jun 2019 11:26:53 +0200 Subject: [PATCH] ALSA: usb-audio: Enable .product_name override for Emagic Unitor 8. The Emagic Unitor 8 does not provide iManufacturer and iProduct fields in its device descriptor. These fields are used by alsa to make build the device name. Thus uncomment the .product-name in the quirks-table. Without this change the device shows up as 'USB Device 0x86a:0x01'. Output of lsusb and amidi: https://gist.github.com/ensonic/7820a102e91f31575be355da2b6b33bc Signed-off-by: Stefan Sauer <ensonic(a)google.com> --- sound/usb/quirks-table.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 9e049f60e80e..e918ce346027 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2408,7 +2408,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), USB_DEVICE(0x086a, 0x0001), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Emagic", - /* .product_name = "Unitor8", */ + .product_name = "Unitor8", .ifnum = 2, .type = QUIRK_MIDI_EMAGIC, .data = & (const struct snd_usb_midi_endpoint_info) { -- 2.21.0

2 1

[alsa-devel] [PATCH] ALSA: snd_ice1712: Check correct return value to snd_i2c_sendbytes (EWS/DMX 6Fire)
by Rui Nuno Capela 11 Jun '19

11 Jun '19

Check for exact and correct return value to snd_i2c_sendbytes call for EWS/DMX 6Fire (snd_ice1712). Fixes a systemic error on every boot starting from kernel 5.1 onwards to snd_ice1712 driver ("cannot send pca") on Terratec EWS/DMX 6Fire PCI soundcards. Signed-off-by: Rui Nuno Capela <rncbc(a)rncbc.org>

2 1

[alsa-devel] Linking ALSA playback devices and DRM connectors
by Ser, Simon 11 Jun '19

11 Jun '19

Hi, I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector. Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD. Am I missing something? If not, what would be the best way to expose this? - A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR? - A symlink to the DRM connector in /sys/class/sound/pcm*? - A DRM connector property? - Somehow expose the connector name via the ALSA API? - Expose the connector EDID via ALSA? - Other ideas? Thanks! Simon Ser

6 8

[alsa-devel] [PATCH 00/15] ALSA: firewire-tascam/fireface: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks
by Takashi Sakamoto 11 Jun '19

11 Jun '19

Hi, This patchset is a part of series of patches for all of drivers in ALSA firewire stack to reserve/release isochronous resources in pcm.hw_params/hw_free callbacks. In current implementation, the resources are reserved at the same time to start packet streaming, and released at the same time to stop packet streaming. However, once allocated, the resources are available independent of lifetime of packet streaming. The isochronous resources are the resources of IEEE 1394 bus. On the other side of view, it's a kind of resources of hardware to maintain the bus (isochronous resource manager). For this kind of reservation and release, hw_params and hw_free operations are suitable in ALSA PCM interface. Ideally, the operation to reserve/release isochronous resource should be separated from the operation to start/stop packet streaming. However, IEEE 1394 bus has reset event. Once reset occurs, isochronous resource manager releases allocated resources. The resources should be reallocated by requesters themselves. For this reason, in this patchset, bus generation is checked before starting packet streaming. If generation is updated, reallocation is requested to isochronous resource manager, then packet streaming starts. Takashi Sakamoto (15): ALSA: firewire-tascam: code refactoring for registration of isochronous channels ALSA: firewire-tascam: code refactoring for reservation of isochronous resources ALSA: firewire-tascam: code refactoring for release of isochronous resources ALSA: firewire-tascam: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks ALSA: firewire-tascam: update isochronous resources when starting packet streaming after bus reset ALSA: firewire-tascam: minor code refactoring to finish streaming session ALSA: firewire-tascam: code refactoring for pcm.hw_params/hw_free callbacks ALSA: fireface: add protocol-specific operation to allocate isochronous resources ALSA: fireface: support allocate_resources operation in ff800 protocol ALSA: fireface: support allocate_resources operation in ff400 protocol ALSA: fireface: support allocate_resources operation in latter protocol ALSA: fireface: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks ALSA: fireface: update isochronous resources when starting packet streaming after bus-reset ALSA: fireface: minor code refactoring to finish streaming session ALSA: fireface: code refactoring for pcm.hw_params/hw_free callbacks sound/firewire/fireface/ff-pcm.c | 57 ++--- sound/firewire/fireface/ff-protocol-former.c | 112 +++++----- sound/firewire/fireface/ff-protocol-latter.c | 114 +++++----- sound/firewire/fireface/ff-stream.c | 85 ++++---- sound/firewire/fireface/ff.h | 3 + sound/firewire/tascam/tascam-pcm.c | 59 ++---- sound/firewire/tascam/tascam-stream.c | 209 ++++++++++--------- sound/firewire/tascam/tascam.h | 2 + 8 files changed, 306 insertions(+), 335 deletions(-) -- 2.20.1

2 17

[alsa-devel] [PATCH] ALSA: oxfw: allow PCM capture for Stanton SCS.1m
by Takashi Sakamoto 11 Jun '19

11 Jun '19

Stanton SCS.1m can transfer isochronous packet with Multi Bit Linear Audio data channels, therefore it allows software to capture PCM substream. However, ALSA oxfw driver doesn't. This commit changes the driver to add one PCM substream for capture direction. Fixes: de5126cc3c0b ("ALSA: oxfw: add stream format quirk for SCS.1 models") Cc: <stable(a)vger.kernel.org> # v4.5+ Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/oxfw/oxfw.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index 3d27f3378d5d..b4bef574929d 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -148,9 +148,6 @@ static int detect_quirks(struct snd_oxfw *oxfw) oxfw->midi_input_ports = 0; oxfw->midi_output_ports = 0; - /* Output stream exists but no data channels are useful. */ - oxfw->has_output = false; - return snd_oxfw_scs1x_add(oxfw); } -- 2.20.1

2 1

[alsa-devel] [PATCH -next] ALSA: lx6464es - Remove set but not used variables 'orun_mask, urun_mask'
by YueHaibing 11 Jun '19

11 Jun '19

Fixes gcc '-Wunused-but-set-variable' warning: sound/pci/lx6464es/lx_core.c: In function 'lx_interrupt_handle_async_events': sound/pci/lx6464es/lx_core.c:990:6: warning: variable 'urun_mask' set but not used [-Wunused-but-set-variable] sound/pci/lx6464es/lx_core.c:989:6: warning: variable 'orun_mask' set but not used [-Wunused-but-set-variable] They are never used, so can be removed. Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- sound/pci/lx6464es/lx_core.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/sound/pci/lx6464es/lx_core.c b/sound/pci/lx6464es/lx_core.c index 9236a1a8c49b..dd3a873777eb 100644 --- a/sound/pci/lx6464es/lx_core.c +++ b/sound/pci/lx6464es/lx_core.c @@ -986,8 +986,6 @@ static int lx_interrupt_handle_async_events(struct lx6464es *chip, u32 irqsrc, * Stat[8] LSB overrun * */ - u64 orun_mask; - u64 urun_mask; int eb_pending_out = (irqsrc & MASK_SYS_STATUS_EOBO) ? 1 : 0; int eb_pending_in = (irqsrc & MASK_SYS_STATUS_EOBI) ? 1 : 0; @@ -1010,9 +1008,6 @@ static int lx_interrupt_handle_async_events(struct lx6464es *chip, u32 irqsrc, *r_notified_out_pipe_mask); } - orun_mask = ((u64)stat[7] << 32) + stat[8]; - urun_mask = ((u64)stat[5] << 32) + stat[6]; - /* todo: handle xrun notification */ return err;

2 1

[alsa-devel] [PATCH] ALSA: firewire-motu: fix destruction of data for isochronous resources
by Takashi Sakamoto 11 Jun '19

11 Jun '19

The data for isochronous resources is not destroyed in expected place. This commit fixes the bug. Cc: <stable(a)vger.kernel.org> # v4.12+ Fixes: 9b2bb4f2f4a2 ("ALSA: firewire-motu: add stream management functionality") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/motu/motu-stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/firewire/motu/motu-stream.c b/sound/firewire/motu/motu-stream.c index 73e7a5e527fc..483a8771d502 100644 --- a/sound/firewire/motu/motu-stream.c +++ b/sound/firewire/motu/motu-stream.c @@ -345,7 +345,7 @@ static void destroy_stream(struct snd_motu *motu, } amdtp_stream_destroy(stream); - fw_iso_resources_free(resources); + fw_iso_resources_destroy(resources); } int snd_motu_stream_init_duplex(struct snd_motu *motu) -- 2.20.1

2 1

[alsa-devel] [PATCH] ASoC: soc-core: call snd_soc_unbind_card() under mutex_lock;
by Kuninori Morimoto 11 Jun '19

11 Jun '19

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit 34ac3c3eb8f0c07 ("ASoC: core: lock client_mutex while removing link components") added mutex_lock() at soc_remove_link_components(). Is is called from snd_soc_unbind_card() snd_soc_unbind_card() => soc_remove_link_components() soc_cleanup_card_resources() soc_remove_dai_links() => soc_remove_link_components() And, there are 2 way to call it. (1) snd_soc_unregister_component() ** mutex_lock() snd_soc_component_del_unlocked() => snd_soc_unbind_card() ** mutex_unlock() (2) snd_soc_unregister_card() => snd_soc_unbind_card() (1) case is already using mutex_lock() when it calles snd_soc_unbind_card(), thus, we will get lockdep warning. We need mutex_lock() under snd_soc_unregister_card() instead of snd_remove_link_components(). Fixes: 34ac3c3eb8f0c07 ("ASoC: core: lock client_mutex while removing link components") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/soc-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 94a36ee..1679990 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1018,14 +1018,12 @@ static void soc_remove_link_components(struct snd_soc_card *card, struct snd_soc_component *component; struct snd_soc_rtdcom_list *rtdcom; - mutex_lock(&client_mutex); for_each_rtdcom(rtd, rtdcom) { component = rtdcom->component; if (component->driver->remove_order == order) soc_remove_component(component); } - mutex_unlock(&client_mutex); } static void soc_remove_dai_links(struct snd_soc_card *card) @@ -2774,7 +2772,9 @@ static void snd_soc_unbind_card(struct snd_soc_card *card, bool unregister) */ int snd_soc_unregister_card(struct snd_soc_card *card) { + mutex_lock(&client_mutex); snd_soc_unbind_card(card, true); + mutex_unlock(&client_mutex); dev_dbg(card->dev, "ASoC: Unregistered card '%s'\n", card->name); return 0; -- 2.7.4

2 2