May 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Internal speaker output from Sony Vaio Z (2010 model) lost somewhere between 3.1.0 and 3.2.6
by Adam Williamson 20 Sep '12

20 Sep '12

Welp, pretty much as the topic says. I just noticed today that sound is no longer playing from the internal speakers of my laptop, a 2010 model Sony Vaio Z. Plugging in headphones causes sound to be played fine through those. There are three possible choices for 'Connector' - 'Analog Speakers', 'Analog Output', and 'Analog Headphones' - but none of these seems to make sound come out of the internal speakers. The default is 'Analog Speakers', and when it's set to this, headphone output does work when headphones are plugged in. I've verified that it's broken on Fedora 16 kernels 3.2.6-4, 3.2.8-3 and 3.2.10-1. It's also broken in a very recent Fedora 17 kernel, 3.3.0rc6 or so. It works on a Fedora 16 live image, with kernel 3.1.0-1. Unfortunately the kernels before 3.2.6 have been trashed from Fedora's buildsystem archives, I think, so it's hard to narrow things down any further :/ the alsa-info output is http://www.alsa-project.org/db/?f=368e2359757b537d4daa0f5399830d3942540196 . Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

3 22

Re: [alsa-devel] M-Audio FastTrack C400
by Grant Diffey 18 Aug '12

18 Aug '12

So this looks reasonably familiar, int0 is DFU int1 is mixer int2 is audio out int3 is audio in int4 is midi int5 is HID Quirk should look like the fast track ultra basically. maybe the mixer is less broken in this device? Should we start with just QUIRK_STANDARD_AUDIO_INTERFACE or copy the whole data section from the Ultra quirk? This has isosyncronous feedback for clock control needs current sound tree usb-audio tree Grant On Wed, Apr 18, 2012 at 8:45 AM, Chris Cavey <chris-alsa(a)rauros.net> wrote: > Will to help with development, may need pointers to get started and > willing to test things. I am mostly concerned with simple playback. > Recording, DSP, and Midi can all come later if at all. > > As requested the output of sudo lsusb -v -d 0763:2030" > > Bus 002 Device 003: ID 0763:2030 Midiman > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 ? > bDeviceProtocol 1 Interface Association > bMaxPacketSize0 64 > idVendor 0x0763 Midiman > idProduct 0x2030 > bcdDevice 1.01 > iManufacturer 1 M-Audio > iProduct 2 Fast Track C400 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 455 > bNumInterfaces 6 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 254 Application Specific Interface > bInterfaceSubClass 1 Device Firmware Update > bInterfaceProtocol 0 > iInterface 6 Fast Track C400 DFU > Device Firmware Upgrade Interface Descriptor: > bLength 9 > bDescriptorType 33 > bmAttributes 1 > Will Not Detach > Manifestation Intolerant > Upload Unsupported > Download Supported > wDetachTimeout 2000 milliseconds > wTransferSize 1024 bytes > bcdDFUVersion 1.10 > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 1 > bInterfaceCount 4 > bFunctionClass 255 Vendor Specific Class > bFunctionSubClass 0 > bFunctionProtocol 32 > iFunction 2 Fast Track C400 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 1 > bInterfaceProtocol 32 > iInterface 2 Fast Track C400 > ** UNRECOGNIZED: 09 24 01 00 02 0a a3 00 00 > ** UNRECOGNIZED: 09 24 0b 80 02 81 82 03 00 > ** UNRECOGNIZED: 08 24 0a 81 03 03 03 00 > ** UNRECOGNIZED: 08 24 0a 82 00 05 03 00 > ** UNRECOGNIZED: 11 24 02 00 01 01 00 80 06 00 00 00 00 00 00 00 00 > ** UNRECOGNIZED: 0c 24 03 01 01 01 00 02 80 00 00 00 > ** UNRECOGNIZED: 11 24 02 02 03 06 00 80 04 00 00 00 00 00 00 00 00 > ** UNRECOGNIZED: 0c 24 03 03 03 06 00 40 80 00 00 00 > ** UNRECOGNIZED: 11 24 09 20 00 00 02 02 00 04 00 00 00 00 00 00 00 > ** UNRECOGNIZED: 15 24 04 40 03 02 00 43 04 00 00 00 00 00 ff ff ff > ff 0f 00 00 > ** UNRECOGNIZED: 10 24 04 42 02 02 00 01 00 00 00 00 00 ff 00 00 > ** UNRECOGNIZED: 10 24 07 43 02 00 42 fd 03 00 00 fd 03 00 00 00 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 32 > iInterface 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 1 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 32 > iInterface 4 Line > ** UNRECOGNIZED: 10 24 01 00 00 01 01 00 00 00 06 00 00 00 00 00 > ** UNRECOGNIZED: 06 24 02 01 03 18 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 37 > Transfer Type Isochronous > Synch Type Asynchronous > Usage Type Implicit feedback Data > wMaxPacketSize 0x00ea 1x 234 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 2 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 32 > iInterface 4 Line > ** UNRECOGNIZED: 10 24 01 00 00 01 d0 00 00 00 02 00 00 00 00 00 > ** UNRECOGNIZED: 06 24 02 03 02 10 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 37 > Transfer Type Isochronous > Synch Type Asynchronous > Usage Type Implicit feedback Data > wMaxPacketSize 0x004e 1x 78 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 32 > iInterface 4 Line > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 1 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 2 > bInterfaceProtocol 32 > iInterface 4 Line > ** UNRECOGNIZED: 10 24 01 00 00 01 01 00 00 00 04 00 00 00 00 00 > ** UNRECOGNIZED: 06 24 02 01 03 18 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 5 > Transfer Type Isochronous > Synch Type Asynchronous > Usage Type Data > wMaxPacketSize 0x009c 1x 156 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 4 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 1 Audio > bInterfaceSubClass 3 MIDI Streaming > bInterfaceProtocol 0 > iInterface 0 > MIDIStreaming Interface Descriptor: > bLength 7 > bDescriptorType 36 > bDescriptorSubtype 1 (HEADER) > bcdADC 1.00 > wTotalLength 35 > MIDIStreaming Interface Descriptor: > bLength 6 > bDescriptorType 36 > bDescriptorSubtype 2 (MIDI_IN_JACK) > bJackType 1 Embedded > bJackID 1 > iJack 0 > MIDIStreaming Interface Descriptor: > bLength 6 > bDescriptorType 36 > bDescriptorSubtype 2 (MIDI_IN_JACK) > bJackType 2 External > bJackID 2 > iJack 0 > MIDIStreaming Interface Descriptor: > bLength 8 > bDescriptorType 36 > bDescriptorSubtype 3 (MIDI_OUT_JACK) > Warning: Descriptor too short > bJackType 1 Embedded > bJackID 3 > bNrInputPins 1 > baSourceID( 0) 2 > BaSourcePin( 0) 1 > iJack 8 > MIDIStreaming Interface Descriptor: > bLength 8 > bDescriptorType 36 > bDescriptorSubtype 3 (MIDI_OUT_JACK) > Warning: Descriptor too short > bJackType 2 External > bJackID 4 > bNrInputPins 1 > baSourceID( 0) 1 > BaSourcePin( 0) 1 > iJack 105 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x07 EP 7 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > MIDIStreaming Endpoint Descriptor: > bLength 5 > bDescriptorType 37 > bDescriptorSubtype 1 (GENERAL) > bNumEmbMIDIJack 1 > baAssocJackID( 0) 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x87 EP 7 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > MIDIStreaming Endpoint Descriptor: > bLength 5 > bDescriptorType 37 > bDescriptorSubtype 1 (GENERAL) > bNumEmbMIDIJack 1 > baAssocJackID( 0) 3 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 5 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 0 No Subclass > bInterfaceProtocol 1 Keyboard > iInterface 0 > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 1.10 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 63 > Report Descriptors: > ** UNAVAILABLE ** > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x86 EP 6 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 8 > Device Qualifier (for other device speed): > bLength 10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 ? > bDeviceProtocol 1 Interface Association > bMaxPacketSize0 64 > bNumConfigurations 1 > Device Status: 0x0000 > (Bus Powered) > > > On 04/17/2012 09:15 AM, Grant Diffey wrote: > > start with an lsusb -v -d (vid:pid) pasted here > > On Tue, Apr 17, 2012 at 10:37 PM, Chris Cavey <chris-alsa(a)rauros.net>wrote: > >> I'd love to be able to help ALSA support this USB sound device. I've >> currently got the device working in a VM on my Ubuntu 12.04 workstation. >> I believe I can capture USB packets. Would this be helpful to anyone? >> Any pointers on where to get started? >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel(a)alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >> > > >

6 26

[alsa-devel] Help requested: new HSS1394 MIDI back-end
by Sean M. Pappalardo - D.J. Pegasus 01 Aug '12

01 Aug '12

Hello everyone. I am a developer for Mixxx, GPL cross-platform digital DJ software: http://www.mixxx.org. My focus is the controller subsystem. I am ready to finally add Linux support for HSS1394 DJ controllers such as Stanton's SCS.1m and SCS.1d. HSS1394 is just MIDI over IEEE1394 (Firewire) at wire speed. The Windows and OSX library source code is LGPL and available on LaunchPad here: https://launchpad.net/hss1394 The Stanton SCS.1m is a sound interface integrated with a two-way control surface that speaks HSS1394. (The sound card uses an Oxford chip set and works fine with FFADO 2.0.1 today up to 96kHz. I use it with Mixxx via JACK.) The Stanton SCS.1d is a two-way control surface (no sound card) that speaks HSS1394 and is capable of sending ALOT of latency-sensitive data: about 4000 messages per platter rotation. (Now imagine if you had four or even two of them on the same network running at +50% speed. This would quickly overwhelm USB, at least at the time these devices were designed.) Read about them here: http://www.stantondj.com/stanton-controllers-systems/system1.html After a lengthy discussion on the FFADO mailing list, we determined that the best (cleanest and most flexible) way to get Linux support for these devices is to write an ALSA kernel driver that speaks HSS1394 with the devices and presents an ALSA MIDI device (with no data rate limits) for each to Linux applications. The advantage of doing this is that the devices will appear to all MIDI applications without them having to have specific support for HSS1394. This means they could be used in DAW applications as well. (FWIW, FFADO trunk has a program called test-scs that does exactly this, but using that is impractical because it depends on various internal parts of the FFADO source so would require bundling all of FFADO with the application, and it's unable to see non-audio devices due to FFADO's intended use (so it sees the SCS.1m but not the .1d.)) So my questions are: where can I find documentation on writing a new MIDI driver for ALSA? And is anyone else interested in helping me do this? Thank you very much for your time and work. Help me take the last step to my dream DJ setup! (Linux, FLAC and SCS.1 controllers.) Sincerely, Sean M. Pappalardo "D.J. Pegasus" Mixxx Developer - Controller Specialist

2 8

[alsa-devel] [PATCH] powerpc: select PPC_CLOCK unconditionally for FSL_SOC
by Shawn Guo 10 Jul '12

10 Jul '12

Freescale PowerPC SoCs share a number of IP blocks with Freescale ARM/IMX SoCs, FlexCAN, SSI, FEC, eSDHC, USB, etc. There are some effort consolidating those drivers to make them work for both architectures. One outstanding difference between two architectures is ARM/IMX will turn off module clocks during platform initialization for power saving and expects drivers manage clocks using clk API, while PowerPC mostly does not do that, and thus does not always build in clk API. Listing all those driver Kconfig options in "select PPC_CLOCK if" seems not scalable for long term maintenance, and could easily introduce Kconfig recursive dependency. This patch chooses to select PPC_CLOCK unconditionally for FSL_SOC to always build clk API for PowerPC in. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- arch/powerpc/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index feab3ba..63fa7fb 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -661,7 +661,7 @@ config SBUS config FSL_SOC bool select HAVE_CAN_FLEXCAN if NET && CAN - select PPC_CLOCK if CAN_FLEXCAN + select PPC_CLOCK config FSL_PCI bool -- 1.7.5.4

2 4

Re: [alsa-devel] emu10k1 driver can't allocate memory
by Takashi Iwai 27 Jun '12

27 Jun '12

At Sun, 20 May 2012 03:04:14 +0200, Mikael Magnusson wrote: > > Hi, (please CC me on replies, not subscribed) > > I recently upgraded to 3.3.6 from 2.6.33.15 (yeah, I know). Since then > I noticed sometimes sounds were sometimes missing, then I noticed > thousands of these in dmesg, > [37280.283484] max memory size is 0x7fffffff (addr = 0x1d5d70071038000)!! I guess you are enabling IOMMU? I guess it translates the address somehow in a way emu10k1 doesn't like. There are really little changes in emu10k1 driver itself, so if the kernel upgrade changes the behavior, it must be in the core part such like IOMMU handling. Try to boot without iommu and see whether it changes the behavior again. Takashi > [37280.283486] emu: failure page = 32 > I also checked asfxload -M output, right after boot it shows all the > synth memory free as you would expect, but after a while of usage, it > is close to 0 (around 50KiB or so). Trying to run a simple program > that writes to /dev/audio fails with > write(3</dev/audio>, > "\32\21\t\3\0\0\4\n\23\34&/6:;94,#\31\17\10\2\0\0\4\v\24\36(07"..., > 4096) = -1 ENOMEM (Cannot allocate memory) > You can also note the output from asfxload -M dropping rapidly while > the program is making sound before it fails. Native alsa apps seem to > fare slightly better as the memory decrease caused by them is actually > returned when they close the device again. > > Loading and unloading soundfonts seem to work as normal, the memory is > returned when the soundfont is unloaded afaict. (I have the patch > applied that makes it possible to load soundfonts (changes the DMA32 > zone to 2GB). I don't think this is the cause of my problem since the > given addresses are way way outside the 4GB range as well.) > > Note that even well before the reported memory is at 0, apps randomly > fail to open the sound output and are silent. Curiously espeak when > successful doesn't cause a decrease in available memory, but when it > fails, it causes about 100KiB drop. > > I can't (don't dare) bisect because this is my production machine, but > I can test patches, or check the major releases between 2.6.33 and > 3.3.6 if you have no idea what causes this. > > I'm not the only one with the problem either, > http://www.google.com/search?nfpr=1&tbs=li:1&q=emu%3A+failure+page+%3D+32+m… > > -- > Mikael Magnusson >

2 3

[alsa-devel] [RFC PATCH] Inverted internal mic
by David Henningsson 25 Jun '12

25 Jun '12

Hi, One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output. This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output. There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because 1) we already have quirking infrastructure there 2) we already have some working quirks already in that layer 3) it would benefit other sound applications that use ALSA directly. The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality. For the most part, this has been some Acer Aspire machines running Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we have proc coefs we can set, but for the other two these proc coefs, if they exist, are unknown to us. Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem? References: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/903853/+attachme… https://bugs.launchpad.net/bugs/903853 -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

5 38

Re: [alsa-devel] [PATCH v3] sound/soc/lapis: add platform driver for ML7213
by Mark Brown 13 Jun '12

13 Jun '12

On Tue, Mar 06, 2012 at 02:48:05PM +0900, Tomoya MORINAGA wrote: > 2012年3月3日1:39 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > > I just merged Lars-Peter's dmaengine library code which has been on the > > list for a week or so - this should be updated to use that next time > > it's posted. That should save a lot of code from the driver and make > > sure it's following best practices for dmaengine use. > Sorry, we can't use this library. This sort of response really isn't on. Do you have some reason for saying this? Flat out refusing to do things with no reason is not useful. > >> +static struct ioh_i2s_data *i2s_data; > >> +static struct ioh_i2s_dma dmadata[MAX_I2S_CH]; > > Why are these needed, aren't they dynamically allocated by the driver? > You mean ASoC driver can't use global variable ? In general no Linux driver should be using a global variable except for things like this. > >> + case SNDRV_PCM_FORMAT_S32_LE: > >> + byte = 24; > >> + break; > > That looks wrong... are you sure you don't support S24_LE or something? > This is correct. > Because maximum transmit size of ML7213's I2S hw is 24bit. Note we often lay out 24 bit audio in 32 bit blocks. > >> +static struct platform_driver ioh_i2s_driver_plat = { > > > >> +static struct platform_driver ioh_dai_driver_plat = { > > > >> +static int ioh_i2s_pci_probe(struct pci_dev *pdev, > >> + const struct pci_device_id *id) > > Why are you creating these platform devices? I don't understand the > > function they serve. The code handling them looks to have quite a few > > problems but I'm not clear they should be there in the first place. > if these platform devices aren't used, device detection doesn't work correctly. > So, I added these. You've not actually mentioned the problem you were seeing... > >> + rv = request_irq(pdev->irq, ioh_i2s_irq, IRQF_SHARED, "ml7213_ioh", > >> + pdev); > >> + if (rv != 0) { > >> + printk(KERN_ERR "Failed to allocate irq\n"); > >> + goto out_irq; > >> + } > > Are you *sure* you're ready to handle interrupts at this point? > This is just registering interrupt handler. > As long as interrupt register is not enabled, the interrupt handler is > not called. > This is common request_irq description. > What's is your concern ? Apart from anything else you've got the interrupt requested as IRQF_SHARED so the interrupt could get called at any time. It's also not clear that you've got the hardware in a known good state.

3 28

[alsa-devel] [RFC] usb-audio: Use a table of mixer controls
by Mark Hills 11 Jun '12

11 Jun '12

Allow mixer controls to be provided clearly in a table, to avoid quantity of error checking at each use. This is definitely clearer than the current code. But going forward, how should this work with the tables defined in mixer_maps.c? I've made this generic and tried to follow existing conventions for similar tables (eg. use a terminator, not array size), comments welcome. --- sound/usb/mixer_quirks.c | 104 +++++++++++++++++++++------------------------- 1 files changed, 48 insertions(+), 56 deletions(-) diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c index 41f4b69..b80b7e7 100644 --- a/sound/usb/mixer_quirks.c +++ b/sound/usb/mixer_quirks.c @@ -42,6 +42,13 @@ extern struct snd_kcontrol_new *snd_usb_feature_unit_ctl; +struct std_mono_table { + unsigned int unitid, control, cmask; + int val_type; + const char *name; + snd_kcontrol_tlv_rw_t *tlv_callback; +}; + /* private_free callback */ static void usb_mixer_elem_free(struct snd_kcontrol *kctl) { @@ -114,6 +121,24 @@ static int snd_create_std_mono_ctl(struct usb_mixer_interface *mixer, } /* + * Create a set of standard UAC controls from a table + */ +static int snd_create_std_mono_table(struct usb_mixer_interface *mixer, + struct std_mono_table *t) +{ + int err; + + while (t->name != NULL) { + err = snd_create_std_mono_ctl(mixer, t->unitid, t->control, + t->cmask, t->val_type, t->name, t->tlv_callback); + if (err < 0) + return err; + } + + return 0; +} + +/* * Sound Blaster remote control configuration * * format of remote control data: @@ -916,61 +941,6 @@ static int snd_ftu_create_mixer(struct usb_mixer_interface *mixer) return 0; } - -/* - * Create mixer for Electrix Ebox-44 - * - * The mixer units from this device are corrupt, and even where they - * are valid they presents mono controls as L and R channels of - * stereo. So we create a good mixer in code. - */ - -static int snd_ebox44_create_mixer(struct usb_mixer_interface *mixer) -{ - int err; - - err = snd_create_std_mono_ctl(mixer, 4, 1, 0x0, USB_MIXER_INV_BOOLEAN, - "Headphone Playback Switch", NULL); - if (err < 0) - return err; - err = snd_create_std_mono_ctl(mixer, 4, 2, 0x1, USB_MIXER_S16, - "Headphone A Mix Playback Volume", NULL); - if (err < 0) - return err; - err = snd_create_std_mono_ctl(mixer, 4, 2, 0x2, USB_MIXER_S16, - "Headphone B Mix Playback Volume", NULL); - if (err < 0) - return err; - - err = snd_create_std_mono_ctl(mixer, 7, 1, 0x0, USB_MIXER_INV_BOOLEAN, - "Output Playback Switch", NULL); - if (err < 0) - return err; - err = snd_create_std_mono_ctl(mixer, 7, 2, 0x1, USB_MIXER_S16, - "Output A Playback Volume", NULL); - if (err < 0) - return err; - err = snd_create_std_mono_ctl(mixer, 7, 2, 0x2, USB_MIXER_S16, - "Output B Playback Volume", NULL); - if (err < 0) - return err; - - err = snd_create_std_mono_ctl(mixer, 10, 1, 0x0, USB_MIXER_INV_BOOLEAN, - "Input Capture Switch", NULL); - if (err < 0) - return err; - err = snd_create_std_mono_ctl(mixer, 10, 2, 0x1, USB_MIXER_S16, - "Input A Capture Volume", NULL); - if (err < 0) - return err; - err = snd_create_std_mono_ctl(mixer, 10, 2, 0x2, USB_MIXER_S16, - "Input B Capture Volume", NULL); - if (err < 0) - return err; - - return 0; -} - void snd_emuusb_set_samplerate(struct snd_usb_audio *chip, unsigned char samplerate_id) { @@ -990,6 +960,27 @@ void snd_emuusb_set_samplerate(struct snd_usb_audio *chip, } } +/* + * The mixer units for Ebox-44 are corrupt, and even where they + * are valid they presents mono controls as L and R channels of + * stereo. So we create provide a good mixer here. + */ +struct std_mono_table ebox44_table[] = { + { 4, 1, 0x0, USB_MIXER_INV_BOOLEAN, "Headphone Playback Switch", NULL }, + { 4, 2, 0x1, USB_MIXER_S16, "Headphone A Mix Playback Volume", NULL }, + { 4, 2, 0x2, USB_MIXER_S16, "Headphone B Mix Playback Volume", NULL }, + + { 7, 1, 0x0, USB_MIXER_INV_BOOLEAN, "Output Playback Switch", NULL }, + { 7, 2, 0x1, USB_MIXER_S16, "Output A Playback Volume", NULL }, + { 7, 2, 0x2, USB_MIXER_S16, "Output B Playback Volume", NULL }, + + { 10, 1, 0x0, USB_MIXER_INV_BOOLEAN, "Input Capture Switch", NULL }, + { 10, 2, 0x1, USB_MIXER_S16, "Input A Capture Volume", NULL }, + { 10, 2, 0x2, USB_MIXER_S16, "Input B Capture Volume", NULL }, + + { } +}; + int snd_usb_mixer_apply_create_quirk(struct usb_mixer_interface *mixer) { int err = 0; @@ -1035,7 +1026,8 @@ int snd_usb_mixer_apply_create_quirk(struct usb_mixer_interface *mixer) break; case USB_ID(0x200c, 0x1018): /* Electrix Ebox-44 */ - err = snd_ebox44_create_mixer(mixer); + /* detection is disabled in mixer_maps.c */ + err = snd_create_std_mono_table(mixer, ebox44_table); break; } -- 1.7.4.4

2 7

[alsa-devel] Internal Mics and Speakers not visible in PulseAudio
by David Henningsson 07 Jun '12

07 Jun '12

Posted to both alsa-devel and pulseaudio-discuss lists, as this is a cross issue. PulseAudio tries to figure out what equipment is present on the machine using the mixer. If it finds e g "Headphone Playback Volume", "Headphone Playback Switch", or "Headphone Jack", it assumes that a headphone is present and creates a headphone port. If it finds no ports, it creates a fallback "Analog Output" port. Now assume that we have a laptop with speakers and a headphone jack, but with only a "Master Playback Volume", and a "Headphone Jack" for the jack detection. PulseAudio will take the "Headphone Jack", and create a headphone port. Now, if this port is currently unconnected/unavailable, it will not show up at all [1]. As a result, the internal speakers - for which no port was created - will be essentially unusable. Now, I thought this was a problem with a pair of machines only, that we could easily quirk on the PulseAudio side. But after looking through Ubuntu bugs and posting a blog post [2] about the issue, I have now collected 21 different machines affected, mostly on the input side. Several Realtek chips are affected on the dmic side, and some older STAC92xx chips have problems in both directions. So it becomes evident to me, that this is something that needs to be fixed pretty fast. So, to move forward, we need to expose these speakers and internal mics to userspace. A very simple (untested) patch is attached. This would make "Internal Mic Jack" and "Speaker Jack" show up. Note that the actual status can be overridden/ignored on the PulseAudio side - the importance here is the sign that there are internal mics and speakers, so that the PulseAudio ports get created. I could develop it a little to make sure we don't actually do any jack detection for these pins but always return them as being true/present. That is, if you approve the idea? I admit that the "Internal Mic Jack" is somewhat misleading/hacky as the internal mic is not connected to any physical jack, but it seems like the simplest way of resolving the problem currently. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic [1] At least in Ubuntu's new Sound Settings UI. [2] http://voices.canonical.com/david.henningsson/2012/05/22/three-audio-bugs-i…

3 8

[alsa-devel] Confusing about Playback/Capture, CODEC/CODEC links, and snd_soc_dapm_link_dai_widgets()
by Stephen Warren 05 Jun '12

05 Jun '12

Mark, Liam, recall the Tegra AHUB structure: > +-------------+ +-----+ +--------------+ +-----+ +------+ > | FIFO pair 0 |<->| CIF |<->| Cross-bar |<->| CIF |<->| I2S0 |<-> External IO > +-------------+ +-----+ | (the "AHUB") | +-----+ +------+ > . . . | | . . . > +-------------+ +-----+ | | +-----+ +------+ > | FIFO pair 3 |<->| CIF |<->| |<->| CIF |<->| I2S4 |<-> External IO > +-------------+ +-----+ | | +-----+ +------+ > | | > | | +-----+ +-------+ > | |<->| CIF |<->| SPDIF |<-> External IO > | | +-----+ +-------+ > | | > | | +-----+ +-------+ > | |<->| CIF |<->| DAM | > | | +-----+ +-------+ > +--------------+ (CIF is AHUB XBAR Client InterFace; basically the DAI or DAI link) I have created a driver for the 4 FIFOs on the left, which exposes 4 (CPU) DAIs. I have created a driver for the AHUB XBAR, which is an ASoC CODEC, and has a DAI for each of the CIFs. There's a CODEC/CODEC link between each FIFO DAI and the relevant AHUB CIF DAI. In order to connect the I2S devices to the AHUB XBAR, I had to make that a CODEC too. This exposes two DAIs; the CIF DAI to connect to the AHUB, and the DAP (Digital Audio Port) DAI to represent the I/O pins on the Tegra package that are connected to the external codec. I have an issue with the paths that snd_soc_dapm_link_dai_widgets() sets up inside both the AHUB XBAR and the I2S. I'll use the I2S to explain since it's internally much simpler. The two DAIs in I2S are roughly: > static const struct snd_soc_dai_driver tegra30_i2s_dais[] = { > { > .playback = { > .stream_name = "DAP Playback", > }, > .capture = { > .stream_name = "DAP Capture", > }, > }, > { > .playback = { > .stream_name = "CIF Playback", > }, > .capture = { > .stream_name = "CIF Capture", > }, > }, > }; For the CIF-side DAI, I instantiated widgets for the AIFs: > static const struct snd_soc_dapm_widget tegra30_i2s_widgets[] = { > SND_SOC_DAPM_AIF_IN("CIF RX", "CIF Playback", 0, SND_SOC_NOPM, 0, 0), > SND_SOC_DAPM_AIF_OUT("CIF TX", "CIF Capture", 0, SND_SOC_NOPM, 0, 0), This works fine; snd_soc_dapm_link_dai_widgets() create a route from the DAI widget "DAP Playback" that feeds into the AIF_IN widget "CIF RX". "works fine" means that the ASoC debugfs files in "asoc/$card/tegra30-i2s.1/dapm/CIF {Playback,RX}" show the expected connections. The DAPM routes inside the I2S are: > static const struct snd_soc_dapm_route tegra30_i2s_routes[] = { > { "DAP TX", NULL, "CIF RX" }, > { "CIF TX", NULL, "DAP RX" }, > }; This also works fine. Now, I instantiated two AIF widgets to interface with the DAP-side DAI: > SND_SOC_DAPM_AIF_IN("DAP RX", "DAP Capture", 0, SND_SOC_NOPM, 0, 0), > SND_SOC_DAPM_AIF_OUT("DAP TX", "DAP Playback", 0, SND_SOC_NOPM, 0, 0), However, this causes snd_soc_dapm_link_dai_widgets() to set up some unexpected paths; "DAP Playback" ends up feeding *into* "DAP TX", rather than feeding from/out of it... > # cat CIF\ Playback > CIF Playback: Off in 0 out 0 > stream CIF Playback inactive > out "static" "CIF RX" > out "static" "CIF RX" > # cat CIF\ RX > CIF RX: Off in 0 out 0 > stream CIF Playback inactive > in "static" "CIF Playback" > in "static" "CIF Playback" > out "static" "DAP TX" > # cat DAP\ TX > DAP TX: Off in 0 out 0 > stream DAP Playback inactive > in "static" "DAP Playback" <<<<<<<<<< > in "static" "DAP Playback" <<<<<<<<<< > in "static" "CIF RX" > # cat DAP\ Playback > DAP Playback: Off in 0 out 0 > stream DAP Playback inactive > out "static" "DAP TX" > out "static" "DAP TX" Now, I can fake this out by swapping the stream names on the DAP-side AIF widgets: > SND_SOC_DAPM_AIF_IN("DAP RX", "DAP Playback", 0, SND_SOC_NOPM, 0, 0), > SND_SOC_DAPM_AIF_OUT("DAP TX", "DAP Capture", 0, SND_SOC_NOPM, 0, 0), Which yields the expected paths in debugfs: > # cat CIF\ Playback > CIF Playback: Off in 0 out 0 > stream CIF Playback inactive > out "static" "CIF RX" > out "static" "CIF RX" > # cat CIF\ RX > CIF RX: Off in 0 out 0 > stream CIF Playback inactive > in "static" "CIF Playback" > in "static" "CIF Playback" > out "static" "DAP TX" > # cat DAP\ TX > DAP TX: Off in 0 out 0 > stream DAP Capture inactive > in "static" "CIF RX" > out "static" "DAP Capture" > out "static" "DAP Capture" > # cat DAP\ Capture > DAP Capture: Off in 0 out 0 > stream DAP Capture inactive > in "static" "DAP TX" > in "static" "DAP TX" But I'm not sure if that's quite correct. In the DAI definitions, is the .playback sub-structure always meant to represent: 1) Playback from the CPU's perspective, in which case the first set of DAP AIF definitions above would be correct or: 2) Is it more that Playback==RX_into_codec, Capture==TX_from_codec? This appears to be supported by the fact that the paths get set up correctly with the second set of AIF definitions above. But if (2) is correct, I wonder why soc_dapm_stream_event()'s first if statement appears to consider the playback_widget of both sides of the DAI to be coupled; wouldn't one side's playback widget be coupled to the other side's capture widget? As an aside, I'm not sure if it's conceptually correct to talk about playback or capture any more (beyond the initial CPU DAI) with arbitrary CODEC/CODEC links, since who knows what kind of routing/CPU->CPU loopbacks/external CODEC->CODEC loopbacks/... might exist in the CODECs? Either way though, something is still not working correctly even when the expected paths show up in debugfs. When I start playback on a PCM exposed by the DMA FIFO driver, I see the relevant AHUB XBAR's stream turned on, and a route exists to the relevant AIF_IN widget, but that widget is not considered to have any outward connections by is_connected_output_ep(), which I think is what is causing it and none of the rest of the path to turn on: (from asoc/$card/asoc/tegra30-ahub-xbar/dapm) > # cat APBIF0\ Playback > APBIF0 Playback: On in 1 out 1 > stream APBIF0 Playback active > out "static" "APBIF0 RX" > out "static" "APBIF0 RX" > # cat APBIF0\ RX > APBIF0 RX: Off in 2 out 0 <<<<< last value shouldn't be 0? > stream APBIF0 Playback inactive <<<<< still inactive? > in "static" "APBIF0 Playback" > in "static" "APBIF0 Playback" > out "APBIF0 RX" "I2S0 TX Mux" even though when I look at all the debugfs files, all the expected paths are there, at least within the AHUB XBAR and I2S drivers, and the external DAI links in the machine driver all probed as expected and bound all the components together. Probably related, the I2S and WM8903 (DAI) drivers aren't being called by the ASoC core to initialize themselves for playback either; pretty much all that happens is that DMA is started. Is the machine driver responsible for this? At this point, I'm not sure whether I have a gross mis-understanding of how this is supposed to work, or whether there are simply bits missing from the DAPM code to fully support CODEC/CODEC links, rather than CPU/CODEC links. Probably slightly related to all of this, but is the following code correct: > int snd_soc_dapm_dai_get_connected_widgets(struct snd_soc_dai *dai, int stream, > struct snd_soc_dapm_widget_list **list) ... > if (stream == SNDRV_PCM_STREAM_PLAYBACK) > paths = is_connected_output_ep(dai->playback_widget, list); > else > paths = is_connected_input_ep(dai->playback_widget, list); I would have expected this to use capture_widget on the final line, but I haven't thought about this in detail, just noticed the lack of symmetry by very brief inspection. Thanks for any help. Sorry for the long email.

4 10