January 2017 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH - alsa-lib 1/1] Change card/pid get functions to return -ENOSYS if the kernel is too old
by Adam Goode 03 Jan '17

03 Jan '17

When trying to get the pid or card of a client, the get functions will return -1 if there is no pid or card for a client. Clients have zero or one of these, so -1 is correct for these cases. But we also need to detect the case where the kernel cannot tell us if there is a card or pid, so that userspace can fallback to probing this information in the old way. Signed-off-by: Adam Goode <agoode(a)google.com> diff --git a/src/seq/seq.c b/src/seq/seq.c index 4405e68..7de1e81 100644 --- a/src/seq/seq.c +++ b/src/seq/seq.c @@ -1522,9 +1522,10 @@ int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info) } /** - * \brief Get the sound card number. + * \brief Get the sound card number if the kernel supports this. * \param info client_info container - * \return card number or -1 if value is not available. + * \return card number, -1 if there is no card for this client, + * or \c -ENOSYS if the kernel does not have support for this operation * * Only available for SND_SEQ_KERNEL_CLIENT clients. */ @@ -1535,9 +1536,10 @@ int snd_seq_client_info_get_card(const snd_seq_client_info_t *info) } /** - * \brief Get the owning PID. + * \brief Get the owning PID if the kernel supports this. * \param info client_info container - * \return pid or -1 if value is not available. + * \return pid, -1 if there is no PID for this client, + * or \c -ENOSYS if the kernel does not have support for this operation * * Only available for SND_SEQ_USER_CLIENT clients. */ diff --git a/src/seq/seq_hw.c b/src/seq/seq_hw.c index 578ef12..a1d1e4a 100644 --- a/src/seq/seq_hw.c +++ b/src/seq/seq_hw.c @@ -102,8 +102,8 @@ static int snd_seq_hw_get_client_info(snd_seq_t *seq, snd_seq_client_info_t * in return -errno; } if (hw->version < SNDRV_PROTOCOL_VERSION(1, 0, 2)) { - info->card = -1; - info->pid = -1; + info->card = -ENOSYS; + info->pid = -ENOSYS; } return 0; } @@ -374,8 +374,8 @@ static int snd_seq_hw_query_next_client(snd_seq_t *seq, snd_seq_client_info_t *i return -errno; } if (hw->version < SNDRV_PROTOCOL_VERSION(1, 0, 2)) { - info->card = -1; - info->pid = -1; + info->card = -ENOSYS; + info->pid = -ENOSYS; } return 0; } -- 2.8.0.rc3.226.g39d4020

5 16

[alsa-devel] [PATCH] ALSA: dice: ensure transmission speed for transmitted packets
by Takashi Sakamoto 03 Jan '17

03 Jan '17

As of kernel 4.10, ALSA dice driver is expected to be used in default speed. In most cases, it's S400. While, IEEE 1394 specification describes the other speed such as S800. According to 'TCD30XX User Guide', its link layer controller supports several transmission speed up to S800[0]. In Dice software interface, transmission speed in output direction can be configured by asynchronous transaction to 'TX_SPEED' offset in its address space. S800 may be available. This commit improves configuration of transmission unit before starting packet streaming for this purpose. The value of 'max_speed' in 'fw_device' data structure has available maximum speed decided in bus arbitration, thus it's within capacity of the unit. [0] TCD3xx User Guide - TCAT 1394 LLC, Revision 0.9.0-41360 (TC Applied Technologies, May 6 2015) http://www.tctechnologies.tc/index.php/support/support-hardware/dice-iii-de… Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/dice/dice-interface.h | 1 + sound/firewire/dice/dice-stream.c | 12 +++++++++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/firewire/dice/dice-interface.h b/sound/firewire/dice/dice-interface.h index 27b044f..47f2c0a 100644 --- a/sound/firewire/dice/dice-interface.h +++ b/sound/firewire/dice/dice-interface.h @@ -251,6 +251,7 @@ /* * The speed at which the packets are sent, SCODE_100-_400; read/write. + * SCODE_800 is only available in Dice III. */ #define TX_SPEED 0x014 diff --git a/sound/firewire/dice/dice-stream.c b/sound/firewire/dice/dice-stream.c index ec4db3a..8573289 100644 --- a/sound/firewire/dice/dice-stream.c +++ b/sound/firewire/dice/dice-stream.c @@ -195,6 +195,7 @@ static int start_streams(struct snd_dice *dice, enum amdtp_stream_direction dir, unsigned int i, pcm_chs, midi_ports; struct amdtp_stream *streams; struct fw_iso_resources *resources; + struct fw_device *fw_dev = fw_parent_device(dice->unit); int err = 0; if (dir == AMDTP_IN_STREAM) { @@ -237,8 +238,17 @@ static int start_streams(struct snd_dice *dice, enum amdtp_stream_direction dir, if (err < 0) return err; + if (dir == AMDTP_IN_STREAM) { + reg[0] = cpu_to_be32(fw_dev->max_speed); + err = snd_dice_transaction_write_tx(dice, + params->size * i + TX_SPEED, + reg, sizeof(reg[0])); + if (err < 0) + return err; + } + err = amdtp_stream_start(&streams[i], resources[i].channel, - fw_parent_device(dice->unit)->max_speed); + fw_dev->max_speed); if (err < 0) return err; } -- 2.9.3

2 1

[alsa-devel] [PATCH] ALSA: oxfw: add support for Mackie Onyx 1640i
by Takashi Sakamoto 03 Jan '17

03 Jan '17

This is for Linux 4.11 development. As of kernel 4.10, ALSA OXFW driver has no entry for Onyx 1640i produced by Mackie (Loud Technologies). This commit supplement it. I note that there're two models produced by Mackie (Loud Technologies), which have the same name 'Onyx 1640i'. The former model based on OXFW970, the latter model based on Dice. This is probably due to low quality of communication of OXFW series. Additionally, the tester reports his or her experiences to get unexpected result at higher sampling transmission frequency as 88.2/96.0 kHz. We didn't have further investigation yet[0]. $ ./linux-firewire-utils/src/crpp < config_rom ROM header and bus information block ----------------------------------------------------------------- 400 042525ce bus_info_length 4, crc_length 37, crc 9678 404 31333934 bus_name "1394" 408 20ff5003 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 5 (64) 40c 000ff205 company_id 000ff2 | 410 00000fcf device_id 0500000fcf | EUI-64 000ff20500000fcf root directory ----------------------------------------------------------------- 414 0006c1b7 directory_length 6, crc 49591 418 03000ff2 vendor 41c 8100000a --> descriptor leaf at 444 420 17001640 model 424 81000011 --> descriptor leaf at 468 428 0c0083c0 node capabilities per IEEE 1394 42c d1000001 --> unit directory at 430 unit directory at 430 ----------------------------------------------------------------- 430 00040b97 directory_length 4, crc 2967 434 1200a02d specifier id: 1394 TA 438 13010001 version: AV/C 43c 17001640 model 440 81000010 --> descriptor leaf at 480 descriptor leaf at 444 ----------------------------------------------------------------- 444 0008a886 leaf_length 8, crc 43142 448 00000000 textual descriptor 44c 00000000 minimal ASCII 450 4c6f7564 "Loud" 454 20546563 " Tec" 458 686e6f6c "hnol" 45c 6f676965 "ogie" 460 7320496e "s In" 464 632e0000 "c." descriptor leaf at 468 ----------------------------------------------------------------- 468 00059fcf leaf_length 5, crc 40911 46c 00000000 textual descriptor 470 00000000 minimal ASCII 474 4f6e7978 "Onyx" 478 20313634 " 164" 47c 30690000 "0i" descriptor leaf at 480 ----------------------------------------------------------------- 480 00059fcf leaf_length 5, crc 40911 484 00000000 textual descriptor 488 00000000 minimal ASCII 48c 4f6e7978 "Onyx" 490 20313634 " 164" 494 30690000 "0i" [0]: [FFADO-user] Mackie 1640i issues (finer details) https://sourceforge.net/p/ffado/mailman/message/35229260/ Tested-by: Seth O'Bannion <saobannion(a)gmail.com> Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/Kconfig | 1 + sound/firewire/oxfw/oxfw.c | 1 + 2 files changed, 2 insertions(+) diff --git a/sound/firewire/Kconfig b/sound/firewire/Kconfig index ab894ed..9f00696 100644 --- a/sound/firewire/Kconfig +++ b/sound/firewire/Kconfig @@ -34,6 +34,7 @@ config SND_OXFW * LaCie Firewire Speakers * Behringer F-Control Audio 202 * Mackie(Loud) Onyx-i series (former models) + * Mackie(Loud) Onyx 1640i (former model) * Mackie(Loud) Onyx Satellite * Mackie(Loud) Tapco Link.Firewire * Mackie(Loud) d.2 pro/d.4 pro diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index e629b88..74d7fb6 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -43,6 +43,7 @@ static bool detect_loud_models(struct fw_unit *unit) const char *const models[] = { "Onyxi", "Onyx-i", + "Onyx 1640i", "d.Pro", "Mackie Onyx Satellite", "Tapco LINK.firewire 4x6", -- 2.9.3

2 1

[alsa-devel] [PATCH v3 0/2] ucm: Automatically load the best config file based on the card long name
by mengdong.lin＠linux.intel.com 03 Jan '17

03 Jan '17

From: Mengdong Lin <mengdong.lin(a)linux.intel.com> Intel DSP platform drivers are used by many different devices. For user space to differentiate them, now ASoC provide API for machine drivers to include the DMI info (vendor, product and board) in card long name. This series will add UCM support for loading best device-specific configuration based on the card long name. For the ASoC kernel patch, please see ASoC: core: Add API to use DMI name in sound card long name (v2) Mengdong Lin (2): ucm: Load device-specific configuration file based on the card long name ucm: Add command 'get _file' to get the config file name of the opened card History: v2: Request the device-specific file name to match the card long name, no long use automatic key word matching and scoring to avoid error and uncertainty. And add command to check the name of actually loaded configuration file. v3: Fix num in strncpy of the long name, which should be MAX_CARD_LONG_NAME - 1, not MAX_CARD_LONG_NAME (80). Mengdong Lin (2): ucm: Load device-specific configuration file based on the card long name ucm: Add command 'get _file' to get the config file name of the opened card include/use-case.h | 1 + src/ucm/main.c | 14 ++++++++ src/ucm/parser.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++--- src/ucm/ucm_local.h | 3 ++ 4 files changed, 115 insertions(+), 4 deletions(-) -- 2.7.4

1 2

[alsa-devel] [PATCH v2 0/2] ucm: Automatically load the best config file based on the card long name
by mengdong.lin＠linux.intel.com 03 Jan '17

03 Jan '17

From: Mengdong Lin <mengdong.lin(a)linux.intel.com> Intel DSP platform drivers are used by many different devices. For user space to differentiate them, now ASoC provide API for machine drivers to include the DMI info (vendor, product and board) in card long name. This series will add UCM support for loading best device-specific configuration based on the card long name. For the ASoC kernel patch, please see ASoC: core: Add API to use DMI name in sound card long name (v2) Mengdong Lin (2): ucm: Load device-specific configuration file based on the card long name ucm: Add command 'get _file' to get the config file name of the opened card History: v2: Request the device-specific file name to match the card long name, no long use automatic key word matching and scoring to avoid error and uncertainty. And add command to check the name of actually loaded configuration file. include/use-case.h | 2 +- src/ucm/main.c | 14 ++++++++ src/ucm/parser.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++--- src/ucm/ucm_local.h | 3 ++ 4 files changed, 115 insertions(+), 5 deletions(-) -- 2.7.4

1 2

[alsa-devel] [PATCH v4] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
by Matt Ranostay 03 Jan '17

03 Jan '17

We can get audio errors if hitting deeper idle states on omaps: [alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)! This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so. Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels. Based on the original patch by Tony Lindgren Link: https://patchwork.kernel.org/patch/9305867/ Cc: Tony Lindgren <tony(a)atomide.com> Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Matt Ranostay <matt(a)ranostay.consulting> --- Changes from v1: * add calculations for latency per number of FIFO locations Changes from v2: * add missing mcbsp.h header change Changes from v3: * base the latency calculations on threshold, buffer size, sample rate, and channels sound/soc/omap/mcbsp.c | 19 +++++++++++++++++++ sound/soc/omap/mcbsp.h | 3 +++ sound/soc/omap/omap-mcbsp.c | 21 ++++++++++++++++++++- 3 files changed, 42 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index 06fec5699cc8..8f792e714894 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -25,6 +25,7 @@ #include <linux/io.h> #include <linux/slab.h> #include <linux/pm_runtime.h> +#include <linux/pm_qos.h> #include <linux/platform_data/asoc-ti-mcbsp.h> @@ -640,9 +641,19 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp) */ void omap_mcbsp_start(struct omap_mcbsp *mcbsp, int tx, int rx) { + struct pm_qos_request *pm_qos_req = &mcbsp->pm_qos_req; int enable_srg = 0; u16 w; + /* Prevent omap hardware from hitting off between fifo fills */ + if (mcbsp->latency) { + if (pm_qos_request_active(pm_qos_req)) + pm_qos_update_request(pm_qos_req, mcbsp->latency); + else + pm_qos_add_request(pm_qos_req, PM_QOS_CPU_DMA_LATENCY, + mcbsp->latency); + } + if (mcbsp->st_data) omap_st_start(mcbsp); @@ -731,6 +742,11 @@ void omap_mcbsp_stop(struct omap_mcbsp *mcbsp, int tx, int rx) if (mcbsp->st_data) omap_st_stop(mcbsp); + + if (mcbsp->active == 1 && pm_qos_request_active(&mcbsp->pm_qos_req)) { + pm_qos_remove_request(&mcbsp->pm_qos_req); + mcbsp->latency = 0; + } } int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id) @@ -1098,6 +1114,9 @@ int omap_mcbsp_init(struct platform_device *pdev) void omap_mcbsp_cleanup(struct omap_mcbsp *mcbsp) { + if (pm_qos_request_active(&mcbsp->pm_qos_req)) + pm_qos_remove_request(&mcbsp->pm_qos_req); + if (mcbsp->pdata->buffer_size) sysfs_remove_group(&mcbsp->dev->kobj, &additional_attr_group); diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h index 61e93b1c185d..d312e72f7979 100644 --- a/sound/soc/omap/mcbsp.h +++ b/sound/soc/omap/mcbsp.h @@ -323,8 +323,11 @@ struct omap_mcbsp { unsigned int fmt; unsigned int in_freq; + unsigned int latency; int clk_div; int wlen; + + struct pm_qos_request pm_qos_req; }; void omap_mcbsp_config(struct omap_mcbsp *mcbsp, diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index d018e966e533..ddaec37fb4c3 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -226,6 +226,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, int wlen, channels, wpf; int pkt_size = 0; unsigned int format, div, framesize, master; + unsigned int buffer_size = mcbsp->pdata->buffer_size; dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream); channels = params_channels(params); @@ -240,7 +241,9 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, default: return -EINVAL; } - if (mcbsp->pdata->buffer_size) { + if (buffer_size) { + int latency; + if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) { int period_words, max_thrsh; int divider = 0; @@ -271,6 +274,22 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, /* Use packet mode for non mono streams */ pkt_size = channels; } + + latency = ((((buffer_size - pkt_size) / channels) * 1000) + / (params->rate_num / params->rate_den)); + + /* + * Use the lowest QoS latency value for active streams, but + * this has the disadvantage of using lower than needed latency + * if an stream with lower QoS ends before one with a higher + * one. Latency setting only gets reset when all streams + * complete. + */ + if (latency <= mcbsp->latency) + mcbsp->latency = latency; + else + mcbsp->latency = 0; + omap_mcbsp_set_threshold(substream, pkt_size); } -- 2.7.4

2 2

[alsa-devel] [PATCH][alsa-lib] topology: fix unused-const-variable warning
by Takashi Sakamoto 02 Jan '17

02 Jan '17

Last year, unused static const variable was added, then compiler generates a below warning. dapm.c:43:30: warning: ‘widget_control_map’ defined but not used [-Wunused-const-variable=] static const struct map_elem widget_control_map[] = { ^~~~~~~~~~~~~~~~~~ This commit removes it. Fixes: 01a0e1a1c219 ("topology: Add DAPM object parser") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- src/topology/dapm.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/src/topology/dapm.c b/src/topology/dapm.c index e830751..8c585a7 100644 --- a/src/topology/dapm.c +++ b/src/topology/dapm.c @@ -39,14 +39,6 @@ static const struct map_elem widget_map[] = { {"dai_link", SND_SOC_TPLG_DAPM_DAI_LINK}, }; -/* mapping of widget kcontrol text names to types */ -static const struct map_elem widget_control_map[] = { - {"volsw", SND_SOC_TPLG_DAPM_CTL_VOLSW}, - {"enum_double", SND_SOC_TPLG_DAPM_CTL_ENUM_DOUBLE}, - {"enum_virt", SND_SOC_TPLG_DAPM_CTL_ENUM_VIRT}, - {"enum_value", SND_SOC_TPLG_DAPM_CTL_ENUM_VALUE}, -}; - static int lookup_widget(const char *w) { unsigned int i; -- 2.9.3

4 8

[alsa-devel] [PATCH][alsa-lib] topology: fix sign-compare warning introduced to set_link_hw_config() and tplg_add_link_object()
by Takashi Sakamoto 02 Jan '17

02 Jan '17

Some functions recently introduced to this library include comparison between variables with different types, then compiler generates below warnings. pcm.c: In function ‘set_link_hw_config’: pcm.c:1179:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < cfg->tx_channels; i++) ^ pcm.c:1183:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < cfg->rx_channels; i++) ^ pcm.c: In function ‘tplg_add_link_object’: pcm.c:1223:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < link->num_streams; i++) ^ pcm.c:1231:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < link->num_hw_configs; i++) This commit suppresses them. Fixes: 6b4d775b9752 ("topology: Parse HW configurations of physical DAI links defined by C API") Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- src/topology/pcm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/topology/pcm.c b/src/topology/pcm.c index 8f8a703..1de8655 100644 --- a/src/topology/pcm.c +++ b/src/topology/pcm.c @@ -1147,7 +1147,7 @@ int tplg_add_pcm_object(snd_tplg_t *tplg, snd_tplg_obj_template_t *t) static int set_link_hw_config(struct snd_soc_tplg_hw_config *cfg, struct snd_tplg_hw_config_template *tpl) { - int i; + unsigned int i; cfg->size = sizeof(*cfg); cfg->id = tpl->id; @@ -1190,7 +1190,7 @@ int tplg_add_link_object(snd_tplg_t *tplg, snd_tplg_obj_template_t *t) struct snd_tplg_link_template *link_tpl = t->link; struct snd_soc_tplg_link_config *link, *_link; struct tplg_elem *elem; - int i; + unsigned int i; if (t->type != SND_TPLG_TYPE_LINK && t->type != SND_TPLG_TYPE_BE && t->type != SND_TPLG_TYPE_CC) -- 2.9.3

3 3

[alsa-devel] [PATCH 0/2 v2] alsa-lib: dynamically adapt the avail_min on the slave
by Jiada Wang 02 Jan '17

02 Jan '17

When configuring avail_min to multiple of slave period size it can happen that user waits one slave period longer than needed for available data. Root cause is implicit grabbing of slave samples in avail_update operation. On next entering poll, the slave will wait for the avail_min threshold reached again, as he is not aware that there are already pending samples in the above layer which are not yet provided to user. Solution is to dynamically adapt the avail_min on the slave. Andreas Pape (2): plugin: dynamically update avail_min on slave rate: dynamic update avail_min on slave src/pcm/pcm_plugin.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++- src/pcm/pcm_plugin.h | 3 +++ src/pcm/pcm_rate.c | 2 +- 3 files changed, 67 insertions(+), 2 deletions(-) -- 2.9.3

2 3

[alsa-devel] [PATCH 3/6] alsa-lib: pcm:dshare enable silence
by sutar.mounesh＠gmail.com 02 Jan '17

02 Jan '17

From: Alexander Jahn <ajahn(a)de.adit-jv.com> This issue depends on system load - if the process using dshare is scheduled fast enough, then there is no noise. A delay of e.g >~2ms produces hearable noise. Reproduction with instrumented aplay(sleep every 100th period for a given time): During the sleep time of 2000000us (2s) the hardware plays old samples in a loop before xrun is detected and recovered after the sleep. This is resolved by placing it in silence, in case of dshare plugin. Signed-off-by: Alexander Jahn <ajahn(a)de.adit-jv.com> Signed-off-by: Andreas Pape <apape(a)de.adit-jv.com> diff --git a/src/pcm/pcm_direct.c b/src/pcm/pcm_direct.c index 4234d66..779845c 100644 --- a/src/pcm/pcm_direct.c +++ b/src/pcm/pcm_direct.c @@ -1240,7 +1240,7 @@ int snd_pcm_direct_initialize_slave(snd_pcm_direct_t *dmix, snd_pcm_t *spcm, str return ret; } - if (dmix->type != SND_PCM_TYPE_DMIX) + if ((dmix->type != SND_PCM_TYPE_DMIX)&&(dmix->type != SND_PCM_TYPE_DSHARE)) goto __skip_silencing; ret = snd_pcm_sw_params_set_silence_threshold(spcm, &sw_params, 0); -- 1.7.9.5

2 1