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

[alsa-devel] HDSPM - Problems with SyncIn
by Andre Schramm 19 Oct '12

19 Oct '12

Hello, I did some tests with the SyncIn-Feature of the HDSPe cards. [root@localhost ~]# lspci |grep Mult 01:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) 02:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) The SyncOut of card 2:00 was plugged to the SyncIn of 1:00 and 1:00 was put to AutoSync-mode automatically upon boot. Problem is that the amixer output seems to be inconsistent and differs from the proc output as well, so I'm not sure which one to trust. [root@localhost ~]# amixer -c0 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=3 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=2 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=1 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=47999 'Preferred Sync Reference' is SyncIn, 'SYNC IN SyncCheck' says 'No Lock', meaning no signal at all, but the 'System Sample Rate' coming from the master card is detected with 1Hz offset. When putting the master to 32000Hz, 31999Hz are shown and so on. [root@localhost ~]# cat /proc/asound/card0/hdspm RME MADI (Card #1) Rev.d2 Status2first3bits: 1 HW Serial: 0x0000019196d4 IRQ: 16 Registers bus: 0xfe9f0000 VM: 0xf8920000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10344ca, ctrl2=0x0, status1=0xc30004, status2=0xc0020361 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: AutoSync Preferred Sync Reference: TCO System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Sync In, Freq=0 (MADI = 3, Word = 3) Input: Coax, Mode=56 channels Now the proc-output reports 'No TCO module detected', which is correct, as no expansion modules where plugged to the cards. But it also says 'Preferred Sync Reference: TCO' and 'Freq=0', where amixer said SyncIn and 47999? Output of the master card is below. Regards, Andre [root@localhost ~]# amixer -c1 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=4 numid=15,iface=MIXER,name='Input Select' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'optical' ; Item #1 'coaxial' : values=0 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=0 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=0 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=48000 [root@localhost ~]# cat /proc/asound/card1/hdspm RME MADI (Card #2) Rev.d2 Status2first3bits: 1 HW Serial: 0x000001b1c606 IRQ: 17 Registers bus: 0xfeaf0000 VM: 0xf9280000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10004da, ctrl2=0x0, status1=0x2800000, status2=0xc0020701 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: Master Preferred Sync Reference: Word Clock System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Input not valid, Freq=0 (MADI = 10, Word = 0) Input: Optical, Mode=56 channels

2 2

[alsa-devel] snd-usb-audio probe problem (Teac UD-H01)
by bEN 13 Oct '12

13 Oct '12

Hi all, the new USB DAC from Teac seems detected as 'Human Interface Device' instead of 'Audio'. Despite the fact it is based on a standard USB Audio class v2 controller (Tenor 8802). Below is dmesg and lsusb outputs. Does it need to apply a patch in /sound/usb/quirks-table.h ? If yes, someone could help me to write this patch, please? Your help would be very much appreciated, Thanks in advance. bEN (from Ubuntu 11.04 with Linux 2.6.38-13-generic + Alsa driver 1.0.23) $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.23. $ dmesg (...) [34035.000078] usb 2-4: new high speed USB device using ehci_hcd and address 3 [34035.151753] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151763] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151770] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151777] usb 2-4: config 1 has no interface number 1 [34035.155108] input: TEAC TEAC USB AUDIO DEVICE as /devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/input/input13 [34035.155328] generic-usb 0003:0644:8038.0002: input,hidraw1: USB HID v1.00 Device [TEAC TEAC USB AUDIO DEVICE] on usb-0000:00:1d.7-4/input0 [34035.202368] Audio class v2 interfaces need an interface association [34035.202387] snd-usb-audio: probe of 2-4:1.2 failed with error -5 [34035.202426] usbcore: registered new interface driver snd-usb-audio $ lsusb -v --> see attachment.

5 6

Re: [alsa-devel] [PATCH 2.6.39-rc3] hda_intel: ALSA HD Audio patch for Intel Panther Point DeviceIDs
by Takashi Iwai 09 Oct '12

09 Oct '12

At Wed, 20 Apr 2011 10:59:57 -0700, Seth Heasley wrote: > > This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. > > Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> Applied now. Thanks. Takashi > --- > --- linux-2.6.39-rc3/sound/pci/hda/hda_intel.c.orig 2011-04-11 17:21:51.000000000 -0700 > +++ linux-2.6.39-rc3/sound/pci/hda/hda_intel.c 2011-04-14 11:44:40.000000000 -0700 > @@ -126,6 +126,7 @@ > "{Intel, ICH10}," > "{Intel, PCH}," > "{Intel, CPT}," > + "{Intel, PPT}," > "{Intel, PBG}," > "{Intel, SCH}," > "{ATI, SB450}," > @@ -2759,6 +2760,8 @@ > { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH }, > /* PBG */ > { PCI_DEVICE(0x8086, 0x1d20), .driver_data = AZX_DRIVER_PCH }, > + /* Panther Point */ > + { PCI_DEVICE(0x8086, 0x1e20), .driver_data = AZX_DRIVER_PCH }, > /* SCH */ > { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH }, > /* Generic Intel */ >

3 2

[alsa-devel] Merging alsa-driver and alsa-kmirror to one GIT repo
by Jaroslav Kysela 26 Sep '12

26 Sep '12

Hi all, I believe, it's time to manage only one GIT repository for the alsa-driver package now. The merge has benefits mainly for the end users - bisecting may work, the correlation between kernel sources and our out-of-kernel build framework becomes more strong. I merged the alsa-driver and alsa-kmirror repos with full history. I also added some code changes to enable the "build-in" mirror tree in Makefile and gitcompile from v1.0.18 (but I don't think that it will be used). The structure of new repository is similar, but the kernel mirrored code is located in the mirror/ subdirectory. The paths are exactly same as in the Linux kernel tree, so possible patches can be applied without any path modifications. Of course, we may create a bash script to do proper and full cherry-picks between kernel and mirrored trees (comments, author, dates). New temporary repository has name alsa-driver.new: http://git.alsa-project.org/?p=alsa-driver.new.git;a=summary The another difference is that the releases are now branches not tags. It allows me to do quick fixes out of the standard development or separate the main development in the release time window (to not include some very new code). The previous branches won't contain probably any additional commits, but it's probably better to play with only one reference scheme. I think that the change from alsa-driver.git to alsa-driver.new.git should be quick. Please, report any objections or acks now. Schedule: When accepted, I will rename the original alsa-driver.git repository to alsa-driver.old.git and move alsa-driver.new.git to alsa-driver.git quickly. 1.0.26 release: This was my last big change (with the ALSA server upgrade) which blocked me to do the 1.0.26 release. I'm going to create new release after the repos switch ASAP. Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.

3 3

[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] [PATCH 4/7] mfd: ab8500-core: Apply the AB8500 CODEC's compatible string to its MFD cell
by Mark Brown 14 Sep '12

14 Sep '12

On Fri, Jul 27, 2012 at 03:36:33PM +0200, Samuel Ortiz wrote: > On Fri, Jul 27, 2012 at 01:38:51PM +0100, Lee Jones wrote: > > Provide a compatible string for the AB8500 CODEC to aid in > > configuration property look-up from its associated Device Tree > > node. > Applied as well. I remain *deeply* unconvinced that this is tasteful design for the device tree bindings, and it's certainly not needed urgently for v3.6 as there's no DT bindings on the CODEC side.

3 2

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] [PATCH 1/6] Bugfixes and clean-ups bound for the v3.6 RCs
by Lee Jones 10 Aug '12

10 Aug '12

This patch-set includes some important changes which should make their way to the Mainline Release Candidates for the v3.6 release. Without them Audio doesn't even probe (at all) when booting with Device Tree selected. The kernel can't compile with ux500 audio enabled. Even if we can get that far SoC Core will assume we're using regmaps and attempt to use them; however, none exist for this driver, so the kernel will oops. arch/arm/mach-ux500/Kconfig | 1 + arch/arm/mach-ux500/board-mop500-msp.c | 2 +- arch/arm/mach-ux500/board-mop500.c | 9 ++++----- sound/soc/codecs/ab8500-codec.c | 4 ++++ sound/soc/soc-dapm.c | 2 -- 5 files changed, 10 insertions(+), 8 deletions(-)

7 49

Re: [alsa-devel] [PATCHv2 - CA0132 HDA Codec 1/2] ALSA: Update Creative CA0132 codec to add DSP features.
by Takashi Iwai 08 Aug '12

08 Aug '12

At Mon, 30 Jul 2012 15:49:00 -0700, Ian Minett wrote: > > >> One thought we have is to handle the spin_lock_irqxxx() as a special > >> case or quirk for the CA0132 codec. Using an approach similar to > >> 'needs_damn_long_delay' in the CA0110 patch, we could define another > >> flag e.g. 'needs_trigger_irqsave' in hda_codec.h struct hda_bus{}. In > >> the CA0132 patch, we would set this flag, which would then be read in > >> hda_intel.c,azx_pcm_trigger(). Either spin_lock_irqxxx() or the current > >> spin_lock() would then be called depending on the flag condition. > >> What is your opinion on an approach like this? Would this be acceptable? > > >No. The fact that you are calling the PCM functions is already > >wrong. The irqsave() is just a side-effect by that, and we can forget > >about it completely now. > > >The only question is where to implement the DSP loader stuff and how. > > Ok, we understand. Given that the codec cannot call into the controller's > PCM interface to load the DSP image, is there an acceptable way you could > recommend for us to add this functionality to the module, without breaking > the architecture? Well, as mentioned earlier, we need to push it up to the controller layer, i.e. hda_intel.c. For example, add a new op for firmware DMA transfer in hda_bus_ops. Could you describe briefly the procedure for the DMA transfer of CA0132? The code looks too complex to follow. thanks, Takashi

2 6

[alsa-devel] [RFC PATCH 0/2] ASoC: add compress stream support
by Vinod Koul 06 Aug '12

06 Aug '12

Here is the much delayed support for compress audio streams in ASoC. This patch series is in RFC form, once we have agreed on this I will send the patches supporting Intel driver as well. Mainly we indicate if the dai is of compressed nature and based on that register a new compressed device. Also the platform driver adds the compress stream operations. Since the codecs handles PCM only, the assumption is that they will not have anything to do here and machine needs to set codec appropriately for compressed streams. In future if codec with such support are available then we can simply add compressed operations into codec as well Comments, criticism welcome... -- Namarta Kohli (1): ASoC: add compress stream support Vinod Koul (1): ASoC: add definations for compressed operations include/sound/compress_driver.h | 1 + include/sound/soc-dai.h | 2 + include/sound/soc.h | 17 ++- sound/soc/Makefile | 2 +- sound/soc/soc-compress.c | 297 +++++++++++++++++++++++++++++++++++++++ sound/soc/soc-core.c | 10 ++- 6 files changed, 326 insertions(+), 3 deletions(-) create mode 100644 sound/soc/soc-compress.c

3 11