Alsa-devel May 2014

alsa-devel@alsa-project.org

130 participants
288 discussions

[alsa-devel] Trouble about Roland UA-11 UA-33 UA-55 and snd-usb-audio module
by FirebUntU 06 Mar '16

06 Mar '16

Hi guys, I write you about support of snd-usb-audio module and a relatively-new gamma of devices from Roland/Edirol: DUO CAPTURE, TRI CAPTURE and QUAD CAPTURE respectively: UA-11, UA-33, UA-55 These aren't not listed in the Alsa db. I have searched a solution for a week and I haven't found a trick to make UA-11 to work under Alsa 1.25.0 then I downloaded the driver for try to patch it and I found these devices is not listed in the tricks table In despair I have played with the switch button called "EXT * **" in the bottom of the unit of UA-11 and magically the device ID is transformed from * 0582:012b to ** 0582:0137 Image: https://dl.dropbox.com/u/32759898/output.jpg (Rear of the UA-11 unit, from the manual) *Before* (Recognized from udev - Unknown from alsa): http://www.alsa-project.org/db/?f=502ee68cf31882ba9ef23525fd66452c34d329e1 *After* (Recognized from udev - Recognized from alsa): http://www.alsa-project.org/db/?f=b2ae3e4331fb3fe613ba71e7aba1ad2e0e6dcd29 In the tricks table header of ALSA the 0582:0137 stay for PM-1000 in /TODO/ statement. I understand the EXT switch, undiscovered in the manual of the DUO CAPTURE is - as the fact - the Advanced Mode. Now the peripherical running both in playback and recording in 16 and 24 bit and without any mixer options in alsamixer. Can you update future releases with this gamma of devices? Awaiting for your positive response :) Thanks. Best regards, Leonardo

9 16

[alsa-devel] Usb audio - unsuported sampling rates
by Gordon Dilan 12 Feb '16

12 Feb '16

Hello, I'm using an usb mic which(according to it's producer should support up to 48kHz sampling rate). The problem is ALSA allows me to use only 16 kHz for this device. I do not want to resample the data, I want to sample it at 48kHz in order to be able to record some high pitch sounds 18-20kHz. I would want to try to do any modifications necessary in order to try support 48kHz, but I'm not sure where to start. Some information: cat /proc/asound/modules ... 1 snd_usb_audio arecord --list-devices **** List of CAPTURE Hardware Devices **** .... card 1: CameraB409241 [USB Camera-B4.09.24.1], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 when I try to use: arecord -v -D hw:1,0 -f S16_LE -c 4 -r 48000 gigi.wav I get this: Recording WAVE 'gigi.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4 Warning: rate is not accurate (requested = 48000Hz, got = 16000Hz) please, try the plug plugin Hardware PCM card 1 'USB Camera-B4.09.24.1' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 4 rate : 16000 exact rate : 16000 (16000/1) msbits : 16 buffer_size : 8000 period_size : 2000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 2000 period_event : 0 start_threshold : 1 stop_threshold : 8000 silence_threshold: 0 silence_size : 0 boundary : 2097152000 appl_ptr : 0 hw_ptr : 0 Any sampling rate I would try higher or lower than 16kHz, I will always get 16000 kHz. Some more information: lsusb Bus 001 Device 007: ID 1415:2000 Nam Tai E&E Products Ltd. or OmniVision Technologies, Inc. Sony Playstation Eye lsusb -t /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M |__ Port 2: Dev 7, If 0, Class=vend., Driver=ov534, 480M |__ Port 2: Dev 7, If 1, Class=audio, Driver=snd-usb-audio, 480M |__ Port 2: Dev 7, If 2, Class=audio, Driver=snd-usb-audio, 480M At the moment I'm looking inside ALSA's source code to try to see from where this limitation of 16000kHz for my device appears, but I have to admit that I'm kind of lost. Any pointers on what direction should I go to try make my desired rate supported would be greatly appreciated! Thank you and best regards, Gordon

3 6

[alsa-devel] [PATCH 0/4] ASoC: fix saif record unwork issue
by Dong Aisheng 16 Jan '16

16 Jan '16

This patch series mainly fixes the saif record unwork issue. The root cause consists of: 1) clk_prepare and clk_enable un-balanced 2) missed setting a proper initial clock rate for saif in dt 3) sgtl5000 dapm widget kcontrol does not work So can not test record on mx28evk. 4) missed setting clkmux mode for saif in dt With this patch series it can fix sgtl5000 widget kcontrol unwork and saif record unwork issue. BTW, just let people konw, i still met a few overruns during record, that's another issue and will be fixed in separte patches later. Patch based on sound-2.6/for-3.6. Dong Aisheng (4): ASoC: mxs-saif: fix clock prepare and enable unbalance issue ASoC: mxs-saif: set a base clock rate for EXTMASTER mode work ASoC: sgtl5000: remove unneeded snd_soc_dapm_new_widgets in probe ARM: mx28evk: add missed clkmux select for saif arch/arm/mach-mxs/mach-mxs.c | 3 +++ sound/soc/codecs/sgtl5000.c | 2 -- sound/soc/mxs/mxs-saif.c | 24 ++++++++++++++++++++++++ 3 files changed, 27 insertions(+), 2 deletions(-)

5 20

[alsa-devel] [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
by Hui Wang 01 Jul '15

01 Jul '15

Most Thinkpad Edge series laptops use conexant codec, so far although the codecs have different minor Vendor Id and minor Subsystem Id, they all belong to the cxt5066 family, this change can make the mute/mic-mute LEDs support more generic among cxt_5066 family. This design refers to the similar solution for the realtek codec ALC269 family in the patch_realtek.c. Cc: Alex Hung <alex.hung(a)canonical.com> Cc: David Henningsson <david.henningsson(a)canonical.com> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_conexant.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index c205bb1..1f2717f 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -3244,9 +3244,29 @@ enum { #if IS_ENABLED(CONFIG_THINKPAD_ACPI) #include <linux/thinkpad_acpi.h> +#include <acpi/acpi.h> static int (*led_set_func)(int, bool); +static acpi_status acpi_check_cb(acpi_handle handle, u32 lvl, void *context, + void **rv) +{ + bool *found = context; + *found = true; + return AE_OK; +} + +static bool is_thinkpad(struct hda_codec *codec) +{ + bool found = false; + if (codec->subsystem_id >> 16 != 0x17aa) + return false; + if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb, &found, NULL)) && found) + return true; + found = false; + return ACPI_SUCCESS(acpi_get_devices("IBM0068", acpi_check_cb, &found, NULL)) && found; +} + static void update_tpacpi_mute_led(void *private_data, int enabled) { struct hda_codec *codec = private_data; @@ -3279,6 +3299,8 @@ static void cxt_fixup_thinkpad_acpi(struct hda_codec *codec, bool removefunc = false; if (action == HDA_FIXUP_ACT_PROBE) { + if (!is_thinkpad(codec)) + return; if (!led_set_func) led_set_func = symbol_request(tpacpi_led_set); if (!led_set_func) { @@ -3494,6 +3516,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = { SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK_VENDOR(0x17aa, "Thinkpad", CXT_FIXUP_THINKPAD_ACPI), SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004", CXT_PINCFG_LEMOTE_A1004), SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205", CXT_PINCFG_LEMOTE_A1205), {} -- 1.8.1.2

7 26

[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 - 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] [RFC][PATCH 00/15 v4] OXFW driver, a succesor to firewire-speakers
by Takashi Sakamoto 26 Oct '14

26 Oct '14

This patchset updates a part of my previous series: [alsa-devel] [RFC v3] [PATCH 00/52] Enhancement for support of firewire devices http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071820.ht… This patchset is based on this series. (This series is under reviewing.) [alsa-devel] [PATCH 00/49 v4] Enhancement for support of Firewire devices http://mailman.alsa-project.org/pipermail/alsa-devel/2014-April/075841.html If you try this patchset, please apply the series in advance and apply this patchset. Or just use backport codes in my github repository: https://github.com/takaswie/snd-firewire-improve Or if you use Ubuntu 14.04, DKMS package is available from David's PPA. (Special thanks to David Henningsson.) https://launchpad.net/~diwic/+archive/snd-firewire-improve If you have Griffin FireWave, I would strongly request to test. Please see 'An issue for FireWave' in this message. == Background Currently, in ALSA, 'firewire-speakers' driver supports OXFW970/971 chipset which Oxford Semiconductor produced. But this driver has some restrictions: - Don't support MIDI substreams - Don't support substreams for PCM/MIDI capturing There are several devices which are based on OXFW970/971. Especially, devices which Behringer and Mackie produced support playback/capture PCM samples/MIDI messages. So firewire-speakers needs re-work to support these devices. This patchset renames 'firewire-speakers' to 'oxfw'. Maintainers already agreed to rename firewire-speakers to suitable name, in my first RFC in Jan 2014. == Supported devices Currently these devices are supported: * Griffin Firewave * LaCie Firewire Speakers * Behringer F-Control Audio 202 * Mackie(Loud) Onyx-i series (former models) * Mackie(Loud) Onyx Satellite * Mackie(Loud) Tapco Link.Firewire These devices can be supported but its IDs are unknown: * Mackie(Loud), d.2 pro * Mackie(Loud), d.4 pro * Mackie(Loud), U.420 * Mackie(Loud), U.420d When you have unknown devices, please inform me output of this command: $ hexdump -C /sys/bus/firewire/devices/fwX/config_rom (X is node id for your device. Tipically '1'.) I tested this driver with Behringer F-Control Audio 202. == Features - Capturing/Playbacking PCM samples/MIDI messages at supported sampling rates via ALSA PCM/MIDI interfaces - Retrieving firewire node information via ALSA hwdep interface - Locking/Unlocking kernel streaming via ALSA hwdep interface - Receiving notification at starting/stopping kernel streaming via ALSA hwdep interface == Solutions for reported regressions Two regressions were reported for my previous series: 1.Some names in card structure is trimmed. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/073128.h… 2.The number of PCM channels are not detected correctly. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/073145.h… The cause of issue 1 is that the device has too long names in its config rom. To solve this issue, for the driver, this patchset uses the same way which firewire-speakers uses, propper alias in device-specific structure. The cause of issue 2 is that the device has several format entries for the same sampling rate: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/073561.h… To solve this issue, this patchset includes improved mechanism to detect stream formation. Additionally, this patchset adds new device entry for Mackie(Loud) Tapco Link.Firewire, refering to FFADO bug ticket 236: http://subversion.ffado.org/ticket/236 == An issue for FireWave I have an issue for Griffin Firewave. This device can handle AV/C Stream Format Information command and driver can get to know stream formations via the command. With Stefan's help, responses from FireWave against this command are clear. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/073561.h… According to these responses, supported formations are: Input Stream to device: Rate PCM MIDI 32000 6 0 44100 6 0 48000 6 0 96000 6 0 32000 2 0 44100 2 0 48000 2 0 0 0 0 0 0 0 0 0 0 (I also expect to get this output from /proc/asound/FireWave/firewire/formation. I note it's order is not important.) But current 'firewire-speakers' has PCM constraints below: - 6ch at 32/44.1/48/96 kHz - 2ch at 48/96 kHz http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/073562.h… So this OXFW driver may lost a support for 2ch/96.0kHz for FireWave and gain 2ch/32.0kHz and 2ch/44.1kHz. I don't know exactly the reason of these gaps. So I strongly hope testers to check these two items: - FireWave really can handle 2ch/96kHz with firewire-speakers driver. - FireWave really can handle 2ch/32.0kHz and 2ch/44.1kHz with oxfw driver. I think a test with aplay is easy to execute: $ aplay -D hw:FireWave -f S32_LE -c 2 -r 96000 /dev/urandom $ aplay -D hw:FireWave -f S32_LE -c 2 -r 48000 /dev/urandom $ aplay -D hw:FireWave -f S32_LE -c 2 -r 44100 /dev/urandom $ aplay -D hw:FireWave -f S32_LE -c 2 -r 32000 /dev/urandom If 2ch/96kHz is apparently available, I'll change codes as a quirk. FYI, when I tested unavailable number of PCM channels with a hack, FCA202 playback PCM substreams but becomes freezed after stopping streaming. $ cat /var/log/syslog ... kernel: [10098.670390] snd_oxfw fw1.0: transaction failed: timeout ... I believe the other OXFW970/971 based devices have a similar behaviour. ================ Takashi Sakamoto (15): speakers: Rename to oxfw and rename some members oxfw: Move to its own directory oxfw: Split stream functionality to a new file and add a header file oxfw: Split PCM functionality to a new file oxfw: Split control functionality to a new file oxfw: Change the way to name card oxfw: Change the way to make PCM rules/constraints oxfw: Add proc interface for debugging purpose oxfw: Change the way to start stream oxfw: Add support for AV/C stream format command to get supported stream formation oxfw: Add a quirk for Griffin FireWave oxfw: Add support for Behringer/Mackie devices oxfw: Add support AMDTP in-stream and PCM capture oxfw: Add support for capture/playback MIDI messages oxfw: Add hwdep interface include/uapi/sound/asound.h | 3 +- include/uapi/sound/firewire.h | 3 +- sound/firewire/Kconfig | 18 +- sound/firewire/Makefile | 3 +- sound/firewire/oxfw/Makefile | 3 + sound/firewire/oxfw/oxfw.c | 284 +++++++++++++ sound/firewire/oxfw/oxfw.h | 141 +++++++ sound/firewire/oxfw/oxfw_command.c | 113 ++++++ sound/firewire/oxfw/oxfw_control.c | 283 +++++++++++++ sound/firewire/oxfw/oxfw_hwdep.c | 190 +++++++++ sound/firewire/oxfw/oxfw_midi.c | 168 ++++++++ sound/firewire/oxfw/oxfw_pcm.c | 367 +++++++++++++++++ sound/firewire/oxfw/oxfw_proc.c | 83 ++++ sound/firewire/oxfw/oxfw_stream.c | 658 ++++++++++++++++++++++++++++++ sound/firewire/speakers.c | 792 ------------------------------------- 15 files changed, 2308 insertions(+), 801 deletions(-) create mode 100644 sound/firewire/oxfw/Makefile create mode 100644 sound/firewire/oxfw/oxfw.c create mode 100644 sound/firewire/oxfw/oxfw.h create mode 100644 sound/firewire/oxfw/oxfw_command.c create mode 100644 sound/firewire/oxfw/oxfw_control.c create mode 100644 sound/firewire/oxfw/oxfw_hwdep.c create mode 100644 sound/firewire/oxfw/oxfw_midi.c create mode 100644 sound/firewire/oxfw/oxfw_pcm.c create mode 100644 sound/firewire/oxfw/oxfw_proc.c create mode 100644 sound/firewire/oxfw/oxfw_stream.c delete mode 100644 sound/firewire/speakers.c -- 1.8.3.2

3 34

[alsa-devel] Audio mini conference 2014?
by Takashi Iwai 03 Sep '14

03 Sep '14

Hi, did anyone think of a meeting in this year? AFAIK, a couple of good candidates to tie with are: - LinuxCon + KS will be at Chicago, USA (in August 18-22) - Plumbers will be at Duesseldorf, Germany (in October 15-17) Any other opportunities? I'm not sure whether I'll be in the former (due to private reason), but very likely I'll attend the latter. And, if we hold a meeting, in which format? I find the previous year's meeting was nice; i.e. a kind of mini-summit that doesn't conflict with other meetings is my preference. But I'm open for other options. thanks, Takashi

14 75

[alsa-devel] icon utrack pro usb audio interface
by Adrien Plisson 29 Aug '14

29 Aug '14

hello, i just bought an "icon utrack pro" usb audio interface <http://www.icon-global.com/ShowPro.aspx?ID=24>. as expected, this interface is not supported under linux: it is not usb audio class compliant, even the midi port is not class compliant... first, i would like to know if anybody ever managed to use this interface under linux: is there an existing driver ? a hack or patch that would allow the kernel to recognize this interface ? a specific module dedicated to this kind of interface ? i can't find any reference to this interface anywhere on the net... anyway, while searching, i found that its firewire counterpart, the "firexon", has an experimental support on ffado. it seems that the firewire interface uses the bridgeco BeBoB chipset. given that some versions of BeBoB supports both firewire and usb, i suppose (but i may be wrong) that the "utrack pro" is also based on BeBoB. is there any other BeBoB based usb interface supported under linux ? finally, i would proudly help the development of a specific driver for this interface: if anyone wants me to test some piece of code, or wants some information on this interface, don't hesitate to contact me. i am also a software developper, so i could help writing a module, but i first need to learn more about the alsa code base (actually, i don't know where to start...). thanks a lot, and have a nice day ! -- rien

3 3

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Alsa-devel May 2014