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

[alsa-devel] SoundBlaster X-fi HD SPDIF fix
by Richard Körber 05 Apr '15

05 Apr '15

Hi! I own a Creative USB SoundBlaster X-fi HD and tried to use its SPDIF optical output. However it didn't work with ALSA out of the box. The reason is that for SPDIF output device #1 must be used. The fix is: In /usr/share/alsa/cards/USB-Audio.conf, change the iec958_device block like this: USB-Audio.pcm.iec958_device { "USB Sound Blaster HD" 1 } Digital output works fine for me after that. BTW, I tried this line in /etc/asound.conf cards.USB-Audio.pcm.iec958_device."USB Sound Blaster HD" 1 but it didn't have any effect. Why was that? Thank you! Regards Richard Körber

2 8

[alsa-devel] [PATCH] add Steinberg UR44 USB Audio Interface support to quirks-table
by Cyrus Harmon 03 Feb '15

03 Feb '15

Signed-off-by: Cyrus Harmon <cyrus(a)bobobeach.com> --- sound/usb/quirks-table.h | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index f652b10..987ca01 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -436,6 +436,36 @@ YAMAHA_DEVICE(0x105d, NULL), } } }, +{ + USB_DEVICE(0x0499, 0x150e), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + /* .vendor_name = "Yamaha", */ + /* .product_name = "Steinberg UR44", */ + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 3, + .type = QUIRK_MIDI_YAMAHA + }, + { + .ifnum = 4, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = -1 + } + } + } +}, YAMAHA_DEVICE(0x2000, "DGP-7"), YAMAHA_DEVICE(0x2001, "DGP-5"), YAMAHA_DEVICE(0x2002, NULL), -- 1.8.3.2

5 32

[alsa-devel] [PATCH] ASoC: davinci-mcasp: Correct rx format unit configuration
by Peter Ujfalusi 14 Jan '15

14 Jan '15

In case of capture we should not use rotation. The reverse and mask is enough to get the data align correctly from the bus to MCU: Format data from bus after reverse (XRBUF) S16_LE: |LSB|MSB|xxx|xxx| |xxx|xxx|MSB|LSB| S24_3LE: |LSB|DAT|MSB|xxx| |xxx|MSB|DAT|LSB| S24_LE: |LSB|DAT|MSB|xxx| |xxx|MSB|DAT|LSB| S32_LE: |LSB|DAT|DAT|MSB| |MSB|DAT|DAT|LSB| With this patch all supported formats will work for playback and capture. Reported-by: Jyri Sarha <jsarha(a)ti.com> (broken S24_3LE capture) Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/davinci/davinci-mcasp.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 6a6b2ff7d7d7..68347b55f6e1 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -467,8 +467,17 @@ static int davinci_config_channel_size(struct davinci_mcasp *mcasp, { u32 fmt; u32 tx_rotate = (word_length / 4) & 0x7; - u32 rx_rotate = (32 - word_length) / 4; u32 mask = (1ULL << word_length) - 1; + /* + * For captured data we should not rotate, inversion and masking is + * enoguh to get the data to the right position: + * Format data from bus after reverse (XRBUF) + * S16_LE: |LSB|MSB|xxx|xxx| |xxx|xxx|MSB|LSB| + * S24_3LE: |LSB|DAT|MSB|xxx| |xxx|MSB|DAT|LSB| + * S24_LE: |LSB|DAT|MSB|xxx| |xxx|MSB|DAT|LSB| + * S32_LE: |LSB|DAT|DAT|MSB| |MSB|DAT|DAT|LSB| + */ + u32 rx_rotate = 0; /* * if s BCLK-to-LRCLK ratio has been configured via the set_clkdiv() -- 2.1.0

3 6

[alsa-devel] "ak" vs "asahi-kasei" (was: Re: [PATCH 3/3 v3] ARM: shmobile: lager: add sound support on DT)
by Geert Uytterhoeven 13 Jan '15

13 Jan '15

Hi Morimoto-san, CC devicetree, alsa-devel On Wed, Jun 11, 2014 at 9:40 AM, Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> wrote: >> On Wed, Jun 11, 2014 at 8:54 AM, Kuninori Morimoto >> <kuninori.morimoto.gx(a)renesas.com> wrote: >> > + compatible = "asahi-kasei,ak4643"; >> >> As Sergei already commented, >> Documentation/devicetree/bindings/vendor-prefixes.txt >> says >> >> ak Asahi Kasei Corp. > > I know, but, > > grep asahi-kasei sound/soc/codecs/* > sound/soc/codecs/ak4104.c: { .compatible = "asahi-kasei,ak4104", }, > sound/soc/codecs/ak4554.c: { .compatible = "asahi-kasei,ak4554" }, > sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4642", .data = &ak4642_drvdata}, > sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4643", .data = &ak4643_drvdata}, > sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4648", .data = &ak4648_drvdata}, > sound/soc/codecs/ak5386.c: { .compatible = "asahi-kasei,ak5386", }, > > ak4642 driver can't probe by "ak"; That's bad. And all but one of these match entries have been added _after_ the addition of "ak" to vendor-prefixes.txt... Outside sound, there's also "asahi-kasei,ak8975" vs. "ak,ak8975". > My code is based on "code", not "document" Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

14 44

Re: [alsa-devel] [FFADO-devel] [RFC] libhinawa: a light-weight I/O library for status/transactions to ALSA FireWire devices
by Jonathan Woithe 12 Jan '15

12 Jan '15

Hi Takashi S On Tue, Sep 23, 2014 at 08:39:34PM +0900, Takashi Sakamoto wrote: > For some reasons (I describe later), I start to develop a light-weight > I/O library for status/transactions to ALSA FireWire devices. > https://github.com/takaswie/libhinawa > > This library gives ways to use ALSA FireWire driver functionality such as > lock/unlock kernel streaming, EFW transaction. This is one of my > solutions to some issues between ALSA/FFADO. As I understand it, this library will be a thin wrapper around whatever kernel interface is used to communicate these details out to userspace (I think byte-type mixer controls are the preferred avenue at present). In principle I have no problem with this approach so long as it remains lightweight. The situation to avoid is the one we had with libraw1394; when the new stack came about the preferred way to interact with it switched back to the native kernel interface since (as I understand the situation) it was felt that libraw1394 didn't really provide a worthwhile API abstraction. Out of interest, is there any signficance in the library's name "hinawa"? > I hope to merge this library into alsa-tools package in future, and this > is a first RFC for it. It's under development and I require your > comments about its APIs and structure ... I will try to find some time to look at the current proposal in the next week or so. > Dice notification is an actual example. Dice based devices transfer > notification to a specific address on host controller. The address space > is exclusive resources on an system. For Dice notification, ALSA Dice > driver gives a way to utilize it for applications As well as Fireworks > situation, some userspace stuffs are needed to use this functionality. For sure. One thing to keep in mind is that while this is an issue for DICE devices it may not apply to others. The library API should be structured to keep in mind that not all features will be needed across the board. We don't want to burden all subsequent firewire-audio streaming drivers with baggage which is only required for a small subset. Regards jonathan

2 2

[alsa-devel] [PATCH - ALSA: snd-virtuoso 1/1] Xonar DSX support
by sgiurgiu11＠gmail.com 04 Jan '15

04 Jan '15

From: Sergiu Giurgiu <sgiurgiu11(a)gmail.com> This patch adds support for ASUS - Xonar DSX sound cards. Tested on openSUSE 12.2 with kernel: Linux 3.4.6-2.10-desktop #1 SMP PREEMPT Thu Jul 26 09:36:26 UTC 2012 (641c197) x86_64 x86_64 x86_64 GNU/Linux Works: - play sounds - adjust volume on master channel. - mute . Since Xonar DS uses the same chip, everything that works for DS should work for DSX as well. Thank you, Sergiu Giurgiu. Signed-off-by: Sergiu Giurgiu <sgiurgiu11(a)gmail.com> diff --git a/mirror/sound/pci/oxygen/virtuoso.c b/mirror/sound/pci/oxygen/virtuoso.c index 3d71423..8104eab 100644 --- a/mirror/sound/pci/oxygen/virtuoso.c +++ b/mirror/sound/pci/oxygen/virtuoso.c @@ -52,6 +52,7 @@ static DEFINE_PCI_DEVICE_TABLE(xonar_ids) = { { OXYGEN_PCI_SUBID(0x1043, 0x835d) }, { OXYGEN_PCI_SUBID(0x1043, 0x835e) }, { OXYGEN_PCI_SUBID(0x1043, 0x838e) }, + { OXYGEN_PCI_SUBID(0x1043, 0x8522) }, { OXYGEN_PCI_SUBID_BROKEN_EEPROM }, { } }; diff --git a/mirror/sound/pci/oxygen/xonar_wm87x6.c b/mirror/sound/pci/oxygen/xonar_wm87x6.c index 63cff90..b555b62 100644 --- a/mirror/sound/pci/oxygen/xonar_wm87x6.c +++ b/mirror/sound/pci/oxygen/xonar_wm87x6.c @@ -1255,7 +1255,6 @@ static void dump_wm87x6_registers(struct oxygen *chip, } static const struct oxygen_model model_xonar_ds = { - .shortname = "Xonar DS", .longname = "Asus Virtuoso 66", .chip = "AV200", .init = xonar_ds_init, @@ -1327,6 +1326,11 @@ int __devinit get_xonar_wm87x6_model(struct oxygen *chip, switch (id->subdevice) { case 0x838e: chip->model = model_xonar_ds; + chip->model.shortname = "Xonar DS"; + break; + case 0x8522: + chip->model = model_xonar_ds; + chip->model.shortname = "Xonar DSX"; break; case 0x835e: chip->model = model_xonar_hdav_slim; -- 1.7.10.4

4 5

[alsa-devel] [PATCH v8 0/2] ASoC: tda998x: add a codec to the HDMI transmitter
by Jean-Francois Moine 02 Jan '15

02 Jan '15

The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link from 2 different sources, I2S and S/PDIF. This patch set first adds an interface between a HDMI transmitter and the HDMI CODEC. The interface is then used by the TDA998x driver to describe its audio capabilities (DAIs), to give the audio constraints of the HDMI device (EDID) to the audio subsystem, and to connect the chosen audio source to the HDMI link. v8: - change some comments about the patches v7: - remove the change of the K predivider (Jyri Sarha) - add S24_3LE and S32_LE as possible audio formats (Jyri Sarha) - don't move the struct priv2 definition and use the slave encoder private data as the device private data (Russell King) - remove the useless request_module (Russell King/Mark Brown) - don't lock the HDMI module (Russell King) - use platform_device_unregister to remove the codec (Russell King) v6: - extend the HDMI CODEC instead of using a specific CODEC v5: - use the TDA998x private data instead of a specific area for the CODEC interface - the CODEC is TDA998x specific (Mark Brown) v4: - remove all the TDA998x specific stuff from the CODEC - move the EDID scan from the CODEC to the TDA998x - move the CODEC to sound/soc (Mark Brown) - update the audio_sample_rate from the EDID (Andrew Jackson) v3: fix bad rate (Andrew Jackson) v2: check double stream start (Mark Brown) Jean-Francois Moine (2): ASoC: hdmi: Add a transmitter interface to the HDMI CODEC drm/i2c: tda998x: Use the HDMI audio CODEC interface .../devicetree/bindings/drm/i2c/tda998x.txt | 18 ++ drivers/gpu/drm/i2c/Kconfig | 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 264 ++++++++++++++++++++- include/sound/hdmi.h | 20 ++ sound/soc/codecs/hdmi.c | 176 +++++++++++++- 5 files changed, 460 insertions(+), 19 deletions(-) create mode 100644 include/sound/hdmi.h -- 2.1.1

3 7

[alsa-devel] [PATCH v3 0/2] Disable the ThinkPad HW mute/level control when possible
by Andy Lutomirski 11 Dec '14

11 Dec '14

This series is being resurrected after several years, and it's quite different from before, so I'm restarting the version numbers :) ThinkPad volume and mute controls are a mess. For whatever reason, ThinkPads have mute buttons that send KEY_MUTE *and* control an invisible-to-ALSA mute switch. Some of them have volume controls that interact with this switch as well. This is a perennial source of problems. On most ThinkPads, if you press mute and then unmute using GUI controls, you have no sound, because userspace and ALSA state gets out of sync with the hardware switch. There's a separate "sound card" that exposes the hardware switch, but userspace code generally doesn't understand that. There are already a few _OSI(Linux) overrides to turn all the hardware buttons into regular buttons. Rather than quirking ACPI everywhere, just teach thinkpad-acpi to program the buttons for full software control and to disable hardware controls. That allows us to remove the ACPI quirks and have normal mute controls. This approach should be much simpler than adding even more kludgey ALSA integration for questionable gain. Tested on an X200s (with latching mute by default) and an X220 (with a mute light and toggle mute by default). Everything works as expected. Changes from v2: - Don't try to change the mute mode on IBM ThinkPads. - Further minor cleanups. - Try to restore the mode on module unload. Changes from v1: - Simplified the code a bit. - Improved suspend/hibernate behavior. Andy Lutomirski (2): thinkpad-acpi: Try to use full software mute control acpi: Remove _OSI(Linux) for ThinkPads drivers/acpi/blacklist.c | 54 ---------------- drivers/platform/x86/thinkpad_acpi.c | 116 ++++++++++++++++++++++++++++++++--- 2 files changed, 106 insertions(+), 64 deletions(-) -- 1.9.3

3 11

[alsa-devel] [PATCH v2] ASoC: rt5677: make volume TLV closer to reality
by Dylan Reid 03 Dec '14

03 Dec '14

The volume blocks have an step of 0.375dB, but TLV uses 0.01dB for units. Switch to use TLV_DB_MINMAX as this allows the minimum to be off by only 0.005dB. This is an improvement from the ~500dB is was misreported by before. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- sound/soc/codecs/rt5677.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 16aa4d9..a4c71f9 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -538,9 +538,9 @@ static bool rt5677_readable_register(struct device *dev, unsigned int reg) } static const DECLARE_TLV_DB_SCALE(out_vol_tlv, -4650, 150, 0); -static const DECLARE_TLV_DB_SCALE(dac_vol_tlv, -65625, 375, 0); +static const DECLARE_TLV_DB_MINMAX(dac_vol_tlv, -6562, 0); static const DECLARE_TLV_DB_SCALE(in_vol_tlv, -3450, 150, 0); -static const DECLARE_TLV_DB_SCALE(adc_vol_tlv, -17625, 375, 0); +static const DECLARE_TLV_DB_MINMAX(adc_vol_tlv, -1762, 0); static const DECLARE_TLV_DB_SCALE(adc_bst_tlv, 0, 1200, 0); static const DECLARE_TLV_DB_SCALE(st_vol_tlv, -4650, 150, 0); -- 2.1.2.330.g565301e

3 6

[alsa-devel] Analog sound (ALC262) lost on linux (any distro and kernel) on a dual boot system
by Ploumistos Alexandros 03 Dec '14

03 Dec '14

Hello, A while back I had installed Ubuntu on a friend's laptop -a Sony Vaio VGN-FW21M- alongside windows Vista. Everything worked fine for a few years, until at some point last year linux went mute, while in windows both the analog and the digital outputs continued working. She couldn't remember doing something "out of the ordinary", but she was sure it was not after an update. Several months later, she upgraded to windows 7 but that didn't change anything. When I got my hands on the laptop, I checked for muted controls and other usual suspects, deprecated quirks (there were none) and all inputs and outputs of the system. HDMI audio works fine and so does the internal mic. Speakers, headphones and the external mic input do not work, even though pulse audio volume meter acts as if there were actually sounds being played. I followed all of Ubuntu's troubleshooting procedures, I removed and reinstalled alsa and pulse, I purged all configuration files, I created a new user and I even installed the latest alsa-packages from the "ALSA daily build snapshots" repository and nothing worked. I also tried booting into windows, setting all volume levels to the max and disabled power saving on all sound and multimedia devices. Next, I tried retasking the jacks one by one to no avail. I remembered that I had performed the installation with an Ubuntu 11.10 live CD, so I booted the computer off of that, but this time I got no sound. I tried with all the live CDs of a multitude of distros I had lying around, with kernels ranging from 2.6.35 to 3.16.6 and none of them worked, so I figured the issue must have something to do with windows. Is it possible that windows somehow started locking the audio chip on shutdown? If that is the case, can it be deduced from the logs and more importantly, can it be fixed? I am attaching the output of alsa-info and lspci as well as kernel logs. Thank you for your time.

2 7