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

[alsa-devel] [PATCH 0/3] ALSA: hda - Avoid potential deadlock
by Thierry Reding 24 Sep '15

24 Sep '15

From: Thierry Reding <treding(a)nvidia.com> The Tegra HDA controller driver committed in v3.16 causes deadlocks when loaded as a module. The reason is that the driver core will lock the HDA controller device upon calling its probe callback and the probe callback then goes on to create child devices for detected codecs and loads their modules via a request_module() call. This is problematic because the new driver will immediately be bound to the device, which will in turn cause the parent of the codec device (the HDA controller device) to be locked again, causing a deadlock. This problem seems to have been present since the modularization of the HD-audio driver in commit 1289e9e8b42f ("ALSA: hda - Modularize HD-audio driver"). On Intel platforms this has been worked around by splitting up the probe sequence into a synchronous and an asynchronous part where the request_module() calls are asynchronous and hence avoid the deadlock. An alternative proposal is provided in this series of patches. Rather than relying on explicit request_module() calls to load kernel modules for HDA codec drivers, this implements a uevent callback for the HDA bus to advertises the MODALIAS information to the userspace helper. Effectively this results in the same modules being loaded, but it uses the more canonical infrastructure to perform this. Deferring the module loading to userspace removes the need for the explicit request_module() calls and works around the recursive locking issue because both drivers will be bound from separate contexts. Thierry Thierry Reding (3): ALSA: hda/hdmi - Add missing MODALIAS information ALSA: hda - Advertise MODALIAS in uevent ALSA: hda: Do not rely on explicit module loading sound/hda/hda_bus_type.c | 12 +++++++ sound/pci/hda/hda_bind.c | 80 ---------------------------------------------- sound/pci/hda/patch_hdmi.c | 3 ++ 3 files changed, 15 insertions(+), 80 deletions(-) -- 2.5.0

3 9

[alsa-devel] ALSA: core: check for underflow in snd_pcm_sw_params()
by Dan Carpenter 24 Sep '15

24 Sep '15

As far as I can see, having an invalid ->tstamp_mode is harmless, but adding a check silences a static checker warning. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 75888dd..4863af5 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -650,7 +650,8 @@ static int snd_pcm_sw_params(struct snd_pcm_substream *substream, } snd_pcm_stream_unlock_irq(substream); - if (params->tstamp_mode > SNDRV_PCM_TSTAMP_LAST) + if (params->tstamp_mode < 0 || + params->tstamp_mode > SNDRV_PCM_TSTAMP_LAST) return -EINVAL; if (params->proto >= SNDRV_PROTOCOL_VERSION(2, 0, 12) && params->tstamp_type > SNDRV_PCM_TSTAMP_TYPE_LAST)

2 1

[alsa-devel] [PATCH] ALSA: oxfw: add Mackie Onyx Satellite quirk to inform wrong value in 'dbs' field in tx CIP header
by Takashi Sakamoto 24 Sep '15

24 Sep '15

Mackie Onyx Satellite has two usage; standalone and with base station. These two modes has different stream formats. In standalone mode, rx data block includes 2 Multi Bit Linear Audio (MBLA) data channels and tx data block includes 2. With base station, they're 6 and 2. Although, with base station, the actual tx packet include wrong value in 'dbs' field in its CIP header. This quirk causes packet streaming layer to detect packet discontinuity and to stop PCM substream. This is a response of 'single' subfunction 'extended stream format information' command in AV/C Stream Format Information Specification 1.1. It means that a data block in tx packets includes 2 MBLA data channels. $ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffffffff response: 000: 0c ff bf c0 01 00 00 00 ff 00 90 40 03 02 01 02 response: 010: 06 Current OXFW driver parses the response and detects stream formats correctly. $ cat /proc/asound/card1/firewire/formation ... Output Stream from device: Rate PCM MIDI * 48000 2 0 44100 2 0 88200 2 0 96000 2 0 On the other hand, in actual tx CIP, the 'dbs' field has 6. But the number of quadlets in CIP payload is not multiple of 6. Seeing the subtraction of two successive payload quadlets, it should be multiple of 2. payload CIP CIP quadlets header0 header1 24 00060052 9002ffff 24 0006005e 9002ffff 26 0006006a 9002ffff 24 00060077 9002ffff 24 00060083 9002ffff 26 0006008f 9002ffff 24 0006009c 9002ffff 24 000600a8 9002ffff 26 000600b4 9002ffff 24 000600c1 9002ffff This commit adds support for this quirk to OXFW driver, by using CIP_WRONG_DBS flag. When this flag is set, packet streaming layer uses the value of its 'data_block_quadlets' member instead of the value in CIP header. This value is already set by OXFW driver and no discontinuity is detected. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/oxfw/oxfw-stream.c | 5 ++++- sound/firewire/oxfw/oxfw.c | 29 +++++++++++++++++++++++++++++ sound/firewire/oxfw/oxfw.h | 1 + 3 files changed, 34 insertions(+), 1 deletion(-) diff --git a/sound/firewire/oxfw/oxfw-stream.c b/sound/firewire/oxfw/oxfw-stream.c index 77ad5b9..863eb4a 100644 --- a/sound/firewire/oxfw/oxfw-stream.c +++ b/sound/firewire/oxfw/oxfw-stream.c @@ -238,9 +238,12 @@ int snd_oxfw_stream_init_simplex(struct snd_oxfw *oxfw, * packets. As a result, next isochronous packet includes more data * blocks than IEC 61883-6 defines. */ - if (stream == &oxfw->tx_stream) + if (stream == &oxfw->tx_stream) { oxfw->tx_stream.flags |= CIP_SKIP_INIT_DBC_CHECK | CIP_JUMBO_PAYLOAD; + if (oxfw->wrong_dbs) + oxfw->tx_stream.flags |= CIP_WRONG_DBS; + } end: return err; } diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index 8c6ce01..d606e3a 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -19,6 +19,8 @@ #define VENDOR_BEHRINGER 0x001564 #define VENDOR_LACIE 0x00d04b +#define MODEL_SATELLITE 0x00200f + #define SPECIFIER_1394TA 0x00a02d #define VERSION_AVC 0x010001 @@ -129,6 +131,31 @@ static void oxfw_card_free(struct snd_card *card) mutex_destroy(&oxfw->mutex); } +static void detect_quirks(struct snd_oxfw *oxfw) +{ + struct fw_device *fw_dev = fw_parent_device(oxfw->unit); + struct fw_csr_iterator it; + int key, val; + int vendor, model; + + /* Seek from Root Directory of Config ROM. */ + vendor = model = 0; + fw_csr_iterator_init(&it, fw_dev->config_rom + 5); + while (fw_csr_iterator_next(&it, &key, &val)) { + if (key == CSR_VENDOR) + vendor = val; + else if (key == CSR_MODEL) + model = val; + } + + /* + * Mackie Onyx Satellite with base station has a quirk to report a wrong + * value in 'dbs' field of CIP header against its format information. + */ + if (vendor == VENDOR_LOUD && model == MODEL_SATELLITE) + oxfw->wrong_dbs = true; +} + static int oxfw_probe(struct fw_unit *unit, const struct ieee1394_device_id *id) { @@ -157,6 +184,8 @@ static int oxfw_probe(struct fw_unit *unit, if (err < 0) goto error; + detect_quirks(oxfw); + err = name_card(oxfw); if (err < 0) goto error; diff --git a/sound/firewire/oxfw/oxfw.h b/sound/firewire/oxfw/oxfw.h index cace5ad..7b5dad8 100644 --- a/sound/firewire/oxfw/oxfw.h +++ b/sound/firewire/oxfw/oxfw.h @@ -49,6 +49,7 @@ struct snd_oxfw { struct mutex mutex; spinlock_t lock; + bool wrong_dbs; bool has_output; u8 *tx_stream_formats[SND_OXFW_STREAM_FORMAT_ENTRIES]; u8 *rx_stream_formats[SND_OXFW_STREAM_FORMAT_ENTRIES]; -- 2.1.4

2 1

Re: [alsa-devel] [Alsa-user] snd-usb-caiaq (NI Maschine Mikro) device not recognised by alsa
by sypwex 24 Sep '15

24 Sep '15

ow, sorry! I not mentioned that there is no PID of Maschine Mikro (0x1110) in caiaq device list *https://github.com/torvalds/linux/blob/v4.2/sound/usb/caiaq/device.h <https://github.com/torvalds/linux/blob/v4.2/sound/usb/caiaq/device.h>* yes there is some endless dump from usbhid but I don't know how to deal with it $sudo usbhid-dump --entity=all --address=1:15 http://pastebin.com/raw.php?i=KC96ERSV (300KiB) ok, I've tried to extend the driver and end up with following doodad https://github.com/krasnobaev/linux/commits/feature/caiaq-mmikro-1 for every commit I've generated dmesg log *http://pastebin.com/raw.php?i=pJzdAyf4 <http://pastebin.com/raw.php?i=pJzdAyf4>* $amidi -l have no devices $cat /proc/asound/cards 4 [MaschineMikro ]: snd-usb-caiaq - Maschine Mikro Native Instruments Maschine Mikro (usb-0000:00:02.1-8) $cat /proc/asound/devices 24: [ 4] : control $cat /proc/asound/oss/sndstat Sound Driver:3.8.1a-980706 (ALSA emulation code) Kernel: Linux ***** 3.19.0+ #1 SMP Sun Sep 13 10:44:23 MSK 2015 x86_64 Config options: 0 Installed drivers: Type 10: ALSA emulation Card config: X-Fi Extreme Audio [SB0790] at 0xdc00 irq 18 HDA NVidia at 0xfcf7c000 irq 19 Aureal Vortex au8810 at 0xfbfc0000 irq 17 Webcam C170 at usb-0000:00:02.1-4, high speed Native Instruments Maschine Mikro (usb-0000:00:02.1-8) Audio devices: 0: CA0106 (DUPLEX) 2: au8810 adb (DUPLEX) 3: USB Audio Synth devices: NOT ENABLED IN CONFIG Midi devices: 0: CA0106 MPU-401 (UART) 2: au8810 MIDI 2 Timers: 31: system timer Mixers: 0: CA0106 1: Nvidia GPU 1c HDMI/DP 2: Wolfson WM9701,WM9701A 3: USB Mixer 4: Maschine Mikro $cat /proc/asound/oss/devices 64: [4- 0]: mixer So, currently customized driver fails (all info in dmesg log) on every usb_submit_urb and usb_set_interface functions, so I've decided to watch wireshark usb logs of windows driver filtered windows log (usb.transfer_type != 0x01) && (usb.device_address == 3) http://filebin.ca/2G6kerv8x9TD/usbpcap-maschine-mikro-win7-x86-3maschinesof… RAW http://filebin.ca/2G6g6civjKfI/usbpcap-maschine-mikro-win7-x86-3maschinesof… filtered log for custom driver http://filebin.ca/2G6kFZxgTTKR/usbpcap-maschine-mikro-ubuntu15.04-linux3.19… RAW http://filebin.ca/2G6oNuU6c6b5/usbpcap-maschine-mikro-ubuntu15.04-linux3.19… the difference is... - windows driver do not send SET INTERFACE request while native caiaq driver is. - windows driver receives Response and Status on each request while caiaq recieves only Response - windows driver send two GET_REPORT with wValues: 0x03f8 and 0x0101 while caiaq driver sends three GET_REPORT requests with wValues: 0x0101, 0x0120, 0x03f8 - windows send 3 SET_REPORT requests with same wValue 0x03f8 while caiaq driver do not send any SET_REPORT request I do not know what means these wValues (0x0101, 0x0120, 0x03f8) and how to find out. Is there probability if linux driver send SET_REPORT requests in the same way as do windows driver - the device will set up correctly? How to send SET REPORT request? I believe that there is no big difference between Maschine Controller and Maschine Mikro. BUT there is no Maschine Mikro on caiaq portfolio http://caiaq.de/references_en.html On Sun, Sep 6, 2015 at 8:02 PM, Clemens Ladisch <cladisch(a)googlemail.com> wrote: > sypwex wrote: > > Native Instruments Mashine Mikro which is snd-usb-caiaq. > > No it's not; the Maschine Mikro is not the same as the Maschine Controller. > > As far as I can see from your lsusb output, the Mikro either works as > a HID input device, or needs a separate driver. To check the first > possibility, try a tool like <https://github.com/DIGImend/usbhid-dump>. > > > Regards, > Clemens > Cheers.

2 6

[alsa-devel] MIDI port using UART interface
by Francesco Lavra 24 Sep '15

24 Sep '15

Hi, I'm looking to use an UART interface as a MIDI in/out port. Since MIDI is an asynchronous serial interface just like UART, and provided a given UART controller is able to operate at 31.25 kbps (in my case, it is) a UART port can be transformed into a MIDI port by adding some hardware components (e.g. an optocopuler) to it, I would have expected to find a generic MIDI<->UART adapter layer in the kernel that bridges the ALSA MIDI interface with UART drivers and allows to operate UARTs as MIDI ports. But apparently there is no such generic adapter, the closest driver I found is for the UART 16550 but this is specific to a type of UART controller different from the one in the platform I'm using (which is i.MX6). So how would you approach the task of writing a MIDI driver that uses UART behind the scenes? Am I correct in assuming that I have to use the RawMIDI interface (as the UART 16550 driver does) to make my MIDI port available to ALSA applications? Or is there a better alternative? Thanks, Francesco

2 2

[alsa-devel] [PATCH] ASOC: fsl_spdif: fix bit order for spdif RX channel status
by Kevin Groeneveld 24 Sep '15

24 Sep '15

The bits within each byte of the hardware registers for the channel status bits are reversed. Therefore when the channel status is read from the hardware we need to reverse the bits. The code which writes the channel status bits for the TX already correctly reverses the bits. This patch implements similar functionality for the RX. I have tested this patch running on imx6 using several different SPDIF source devices. Signed-off-by: Kevin Groeneveld <kgroeneveld(a)lenbrook.com> --- sound/soc/fsl/fsl_spdif.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c index ab729f2..e84e839 100644 --- a/sound/soc/fsl/fsl_spdif.c +++ b/sound/soc/fsl/fsl_spdif.c @@ -676,14 +676,14 @@ static int fsl_spdif_capture_get(struct snd_kcontrol *kcontrol, return -EAGAIN; regmap_read(regmap, REG_SPDIF_SRCSH, &cstatus); - ucontrol->value.iec958.status[0] = (cstatus >> 16) & 0xFF; - ucontrol->value.iec958.status[1] = (cstatus >> 8) & 0xFF; - ucontrol->value.iec958.status[2] = cstatus & 0xFF; + ucontrol->value.iec958.status[0] = bitrev8((cstatus >> 16) & 0xFF); + ucontrol->value.iec958.status[1] = bitrev8((cstatus >> 8) & 0xFF); + ucontrol->value.iec958.status[2] = bitrev8(cstatus & 0xFF); regmap_read(regmap, REG_SPDIF_SRCSL, &cstatus); - ucontrol->value.iec958.status[3] = (cstatus >> 16) & 0xFF; - ucontrol->value.iec958.status[4] = (cstatus >> 8) & 0xFF; - ucontrol->value.iec958.status[5] = cstatus & 0xFF; + ucontrol->value.iec958.status[3] = bitrev8((cstatus >> 16) & 0xFF); + ucontrol->value.iec958.status[4] = bitrev8((cstatus >> 8) & 0xFF); + ucontrol->value.iec958.status[5] = bitrev8(cstatus & 0xFF); /* Clear intr */ regmap_write(regmap, REG_SPDIF_SIC, INT_CNEW); -- 1.7.4.1

2 1

[alsa-devel] [PATCH 1/4] ASoC: rt5645: Remove the repeated definitions
by Oder Chiou 23 Sep '15

23 Sep '15

Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5645.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/codecs/rt5645.h b/sound/soc/codecs/rt5645.h index 90325d9..f45861c 100644 --- a/sound/soc/codecs/rt5645.h +++ b/sound/soc/codecs/rt5645.h @@ -777,8 +777,6 @@ #define RT5645_PWR_CLS_D_R_BIT 9 #define RT5645_PWR_CLS_D_L (0x1 << 8) #define RT5645_PWR_CLS_D_L_BIT 8 -#define RT5645_PWR_ADC_R (0x1 << 1) -#define RT5645_PWR_ADC_R_BIT 1 #define RT5645_PWR_DAC_L2 (0x1 << 7) #define RT5645_PWR_DAC_L2_BIT 7 #define RT5645_PWR_DAC_R2 (0x1 << 6) -- 1.8.1.1.439.g50a6b54

2 7

[alsa-devel] [PATCH] topology: Add API to set a vendor specific version number
by mengdong.lin＠intel.com 23 Sep '15

23 Sep '15

From: Mengdong Lin <mengdong.lin(a)intel.com> This vendor-specific version number is optional. It will be written to the 'version' field of each block header of the binary toplogy data file. The vendor driver can check this number for further processing in kernel. The topology ABI version number is still stored in the 'abi' field of block headers. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> --- include/topology.h | 8 ++++++++ src/topology/builder.c | 6 +++--- src/topology/parser.c | 7 +++++++ 3 files changed, 18 insertions(+), 3 deletions(-) diff --git a/include/topology.h b/include/topology.h index 6ff8c5f..9b84bd9 100644 --- a/include/topology.h +++ b/include/topology.h @@ -690,6 +690,14 @@ int snd_tplg_build(snd_tplg_t *tplg, const char *outfile); */ int snd_tplg_set_manifest_data(snd_tplg_t *tplg, const void *data, int len); +/** + * \brief Set an optional vendor specific version number. + * \param tplg Topology instance. + * \param version Vendor specific version number. + * \return Zero on success, otherwise a negative error code + */ +int snd_tplg_set_version(snd_tplg_t *tplg, unsigned int version); + /* \} */ #ifdef __cplusplus diff --git a/src/topology/builder.c b/src/topology/builder.c index 3bccd44..2f01137 100644 --- a/src/topology/builder.c +++ b/src/topology/builder.c @@ -89,7 +89,7 @@ static int write_data_block(snd_tplg_t *tplg, int size, int tplg_type, /* write the header for this block */ ret = write_block_header(tplg, tplg_type, 0, - SND_SOC_TPLG_ABI_VERSION, 0, size, 1); + tplg->version, 0, size, 1); if (ret < 0) { SNDERR("error: failed to write %s block %d\n", obj_name, ret); return ret; @@ -125,7 +125,7 @@ static int write_elem_block(snd_tplg_t *tplg, } ret = write_block_header(tplg, tplg_type, vendor_type, - SND_SOC_TPLG_ABI_VERSION, 0, size, count); + tplg->version, 0, size, count); if (ret < 0) { SNDERR("error: failed to write %s block %d\n", obj_name, ret); @@ -243,7 +243,7 @@ static int write_manifest_data(snd_tplg_t *tplg) /* write the header for this block */ ret = write_block_header(tplg, SND_SOC_TPLG_TYPE_MANIFEST, 0, - SND_SOC_TPLG_ABI_VERSION, 0, + tplg->version, 0, sizeof(tplg->manifest) + tplg->manifest.priv.size, 1); if (ret < 0) { SNDERR("error: failed to write manifest block %d\n", ret); diff --git a/src/topology/parser.c b/src/topology/parser.c index 7ca244c..c0ab5e4 100644 --- a/src/topology/parser.c +++ b/src/topology/parser.c @@ -362,6 +362,13 @@ int snd_tplg_set_manifest_data(snd_tplg_t *tplg, const void *data, int len) return 0; } +int snd_tplg_set_version(snd_tplg_t *tplg, unsigned int version) +{ + tplg->version = version; + + return 0; +} + void snd_tplg_verbose(snd_tplg_t *tplg, int verbose) { tplg->verbose = verbose; -- 1.9.1

5 4

[alsa-devel] [PATCH - 1/2] HDA - Add SND_JACK_HEADSET and Headset jack kctl
by Raymond Yau 23 Sep '15

23 Sep '15

>From b3ed187912eccf922000aee09c04f9546b068925 Mon Sep 17 00:00:00 2001 From: Raymond Yau <superquad.vortex2(a)gmail.com> Date: Sun, 20 Sep 2015 22:10:18 +0800 Subject: [PATCH - 1/2] HDA - Add SND_JACK_HEADSET and Headset jack kctl add headset jack kctl for alsa jack type SND_JACK_HEADSET skip creation of Headset Mic Phantom Jack use Headset Playback Volume and Headset Playback Switch allow auto mic selection by using HP pin for jack sense Signed-off-by: Raymond Yau <superquad.vortex2(a)gmail.com> diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 24f9111..ce6da6f 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -2140,7 +2140,8 @@ static int create_hp_out_ctls(struct hda_codec *codec) struct hda_gen_spec *spec = codec->spec; return create_extra_outs(codec, spec->autocfg.hp_outs, spec->hp_paths, - "Headphone"); + spec->hs_mic_use_hp_sense ? + "Headset" : "Headphone"); } static int create_speaker_out_ctls(struct hda_codec *codec) @@ -4362,6 +4363,16 @@ void snd_hda_gen_line_automute(struct hda_codec *codec, } EXPORT_SYMBOL_GPL(snd_hda_gen_line_automute); +bool is_headset_mic(struct auto_pin_cfg *cfg, hda_nid_t pin) +{ + int i; + + for (i = 0; i < cfg->num_inputs; i++) + if (cfg->inputs[i].pin == pin) + return cfg->inputs[i].is_headset_mic; + return 0; +} + /** * snd_hda_gen_mic_autoswitch - standard mic auto-switch helper * @codec: the HDA codec @@ -4381,6 +4392,9 @@ void snd_hda_gen_mic_autoswitch(struct hda_codec *codec, /* don't detect pins retasked as outputs */ if (snd_hda_codec_get_pin_target(codec, pin) & AC_PINCTL_OUT_EN) continue; + if (spec->hs_mic_use_hp_sense && + is_headset_mic(&spec->autocfg, pin)) + pin = auto_cfg_hp_pins(&spec->autocfg)[0]; if (snd_hda_jack_detect_state(codec, pin) == HDA_JACK_PRESENT) { mux_select(codec, 0, spec->am_entry[i].idx); return; @@ -4662,7 +4676,9 @@ static int check_auto_mic_availability(struct hda_codec *codec) if (!spec->line_in_auto_switch && cfg->inputs[i].type != AUTO_PIN_MIC) return 0; /* only mic is allowed */ - if (!is_jack_detectable(codec, nid)) + if (!is_jack_detectable(codec, nid) && + !(cfg->inputs[i].is_headset_mic && + spec->hs_mic_use_hp_sense)) return 0; /* no unsol support */ break; } diff --git a/sound/pci/hda/hda_generic.h b/sound/pci/hda/hda_generic.h index 56e4139..96f8214 100644 --- a/sound/pci/hda/hda_generic.h +++ b/sound/pci/hda/hda_generic.h @@ -236,6 +236,7 @@ struct hda_gen_spec { unsigned int indep_hp_enabled:1; /* independent HP enabled */ unsigned int have_aamix_ctl:1; unsigned int hp_mic_jack_modes:1; + unsigned int hs_mic_use_hp_sense:1; /* additional mute flags (only effective with auto_mute_via_amp=1) */ u64 mute_bits; diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index 366efbf..5fa8ace 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -19,6 +19,7 @@ #include "hda_local.h" #include "hda_auto_parser.h" #include "hda_jack.h" +#include "hda_generic.h" /** * is_jack_detectable - Check whether the given pin is jack-detectable @@ -350,11 +351,14 @@ EXPORT_SYMBOL_GPL(snd_hda_jack_report_sync); static int get_input_jack_type(struct hda_codec *codec, hda_nid_t nid) { unsigned int def_conf = snd_hda_codec_get_pincfg(codec, nid); + struct hda_gen_spec *spec = codec->spec; switch (get_defcfg_device(def_conf)) { case AC_JACK_LINE_OUT: case AC_JACK_SPEAKER: return SND_JACK_LINEOUT; case AC_JACK_HP_OUT: + if (spec->hs_mic_use_hp_sense) + return SND_JACK_HEADSET; return SND_JACK_HEADPHONE; case AC_JACK_SPDIF_OUT: case AC_JACK_DIG_OTHER_OUT: @@ -434,6 +438,7 @@ static int add_jack_kctl(struct hda_codec *codec, hda_nid_t nid, char name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN]; int err; bool phantom_jack; + struct hda_gen_spec *spec = codec->spec; if (!nid) return 0; @@ -446,8 +451,13 @@ static int add_jack_kctl(struct hda_codec *codec, hda_nid_t nid, if (base_name) strlcpy(name, base_name, sizeof(name)); - else + else { snd_hda_get_pin_label(codec, nid, cfg, name, sizeof(name), NULL); + if ((strcmp(name, "Headphone") == 0) && + (nid == auto_cfg_hp_pins(cfg)[0]) && + spec->hs_mic_use_hp_sense) + strlcpy(name, "Headset", sizeof(name)); + } if (phantom_jack) /* Example final name: "Internal Mic Phantom Jack" */ strncat(name, " Phantom", sizeof(name) - strlen(name) - 1); @@ -469,6 +479,7 @@ int snd_hda_jack_add_kctls(struct hda_codec *codec, const struct auto_pin_cfg *cfg) { const hda_nid_t *p; + struct hda_gen_spec *spec = codec->spec; int i, err; for (i = 0; i < cfg->num_inputs; i++) { @@ -482,6 +493,10 @@ int snd_hda_jack_add_kctls(struct hda_codec *codec, err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg, "Headphone Mic"); } else + if (cfg->inputs[i].is_headset_mic && + spec->hs_mic_use_hp_sense) + err = 0; + else err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg, NULL); if (err < 0) -- 2.5.0

2 2

[alsa-devel] [PATCH utils] aplay: fix VU meter for S24_LE etc formats
by Ricard Wanderlof 23 Sep '15

23 Sep '15

When recording or playing back audio in a format where the number of significant bits is less than the physical width (e.g. S24_LE), the VU meter code needs to consider the number of significant bits in the samples rather than the physical sample width (e.g. 24 vs 32 bits). Otherwise the resulting VU meter display will be far too low and it will just indicate 0% all the time. Tested with a device supporting the S24_LE format. Signed-off-by: Ricard Wanderlof <ricardw(a)axis.com> --- alsa-utils/aplay/aplay.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/aplay/aplay.c b/aplay/aplay.c index e58e1bc..19b6a92 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -124,7 +124,7 @@ static int fatal_errors = 0; static int verbose = 0; static int vumeter = VUMETER_NONE; static int buffer_pos = 0; -static size_t bits_per_sample, bits_per_frame; +static size_t significant_bits_per_sample, bits_per_sample, bits_per_frame; static size_t chunk_bytes; static int test_position = 0; static int test_coef = 8; @@ -1344,6 +1344,7 @@ static void set_params(void) snd_pcm_dump(handle, log); bits_per_sample = snd_pcm_format_physical_width(hwparams.format); + significant_bits_per_sample = snd_pcm_format_width(hwparams.format); bits_per_frame = bits_per_sample * hwparams.channels; chunk_bytes = chunk_size * bits_per_frame / 8; audiobuf = realloc(audiobuf, chunk_bytes); @@ -1745,7 +1746,7 @@ static void compute_max_peak(u_char *data, size_t count) } return; } - max = 1 << (bits_per_sample-1); + max = 1 << (significant_bits_per_sample-1); if (max <= 0) max = 0x7fffffff; -- 1.7.10.4 -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 1