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

[alsa-devel] Fwd: Support for Roland VG-99 (working code, but could use help)
by Pete Leigh 20 Oct '12

20 Oct '12

Hi, I tried posting this a couple of days ago, but no response... I'm wondering if the (text) attachment stopped people from seeing it, or if there's something else I missed? It's just a request to look over the lsusb output and new quirks-table entry included, with a view to getting this added to a release. Since the initial post, I've done more testing (I'm using a kernel based on 3.4.11-1.rt19.1.fc17.ccrma.x86_64.rt) and everything seems to work fine (including midi in, which I wasn't sure of at the time of posting) apart from one apparently cosmetic issue - the device name no longer shows up in lsusb output, though it did before applying the quirk. (?) I'll include the quirk entry as text rather than an attachment this time. If I actually need to go through the process of generating a patch and sending mail via git, as per the developer page on the alsa-project site, could someone let me know, and I'll give it a go (it's something I was hoping to avoid, I admit!) Thanks, - Pete. ---------- Forwarded message ---------- The VG-99 is a guitar processor with a usb interface which offers 2x16bit 44100 pcm in and out streams in its basic usb mode, and 2x24bit 44100 in/out + midi in the advanced mode connection mode. Basic mode works fine with usb snd driver, but the device isn't recognised when set to advanced mode (this is done under USB on page 2 of the "system" config menu) I've used the lsusb -v output (below) to guess at an addition to sound/usb/quirks-table.h to try and get this working. On initial (brief) testing, audio in/out at 24bits (as shown by jackd output) and midi (out, at least) are all working. I'll attach the quirk, and would be pleased if someone could look at it, and the lsusb output, and fix up any deficiencies (it's purely voodoo here :-D) and maybe get it or something like it into the official source... please let me know if changes need to be tested. Cheers, - Pete. Here's the lsusb output: Bus 001 Device 007: ID 0582:00b2 Roland Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 8 idVendor 0x0582 Roland Corp. idProduct 0x00b2 bcdDevice 1.00 iManufacturer 1 Roland iProduct 2 VG-99 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 167 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 02 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Device Status: 0x0001 Self Powered ------------------------------------ And the quirk entry: { USB_DEVICE(0x0582, 0x00b2), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Roland", .product_name = "VG-99", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_3LE, .channels = 2, .iface = 0, .altsetting = 1, .altset_idx = 1, .attributes = 0, .endpoint = 0x01, .ep_attr = 0x09, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_3LE, .channels = 2, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_FILL_MAX, .endpoint = 0x82, .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0007, .in_cables = 0x0007 } }, { .ifnum = -1 } } } },

3 18

[alsa-devel] [PATCH v3 1/3] ALSA: core: keep track of boundary wrap-around
by Pierre-Louis Bossart 19 Oct '12

19 Oct '12

Keep track of boundary crossing when hw_ptr exceeds boundary limit and wraps-around. This will help keep track of total number of frames played/received at the kernel level Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- include/sound/pcm.h | 1 + sound/core/pcm_lib.c | 25 ++++++++++++++++++++----- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index cdca2ab..ba13e0b 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -281,6 +281,7 @@ struct snd_pcm_runtime { unsigned long hw_ptr_jiffies; /* Time when hw_ptr is updated */ unsigned long hw_ptr_buffer_jiffies; /* buffer time in jiffies */ snd_pcm_sframes_t delay; /* extra delay; typically FIFO size */ + u64 hw_ptr_wrap; /* offset for hw_ptr due to boundary wrap-around */ /* -- HW params -- */ snd_pcm_access_t access; /* access mode */ diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 7ae6719..bbc6ba4 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -315,6 +315,7 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, unsigned long jdelta; unsigned long curr_jiffies; struct timespec curr_tstamp; + int crossed_boundary = 0; old_hw_ptr = runtime->status->hw_ptr; @@ -359,8 +360,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, hdelta = curr_jiffies - runtime->hw_ptr_jiffies; if (hdelta > runtime->hw_ptr_buffer_jiffies/2) { hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; goto __delta; } @@ -370,8 +373,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, /* pointer crosses the end of the ring buffer */ if (new_hw_ptr < old_hw_ptr) { hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; } __delta: @@ -409,8 +414,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, while (hdelta > xrun_threshold) { delta += runtime->buffer_size; hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; hdelta -= runtime->hw_ptr_buffer_jiffies; } @@ -455,8 +462,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, /* the delta value is small or zero in most cases */ while (delta > 0) { new_hw_ptr += runtime->period_size; - if (new_hw_ptr >= runtime->boundary) + if (new_hw_ptr >= runtime->boundary) { new_hw_ptr -= runtime->boundary; + crossed_boundary--; + } delta--; } /* align hw_base to buffer_size */ @@ -506,6 +515,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, runtime->hw_ptr_base = hw_base; runtime->status->hw_ptr = new_hw_ptr; runtime->hw_ptr_jiffies = curr_jiffies; + if (crossed_boundary) { + snd_BUG_ON(crossed_boundary != 1); + runtime->hw_ptr_wrap += runtime->boundary; + } if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) runtime->status->tstamp = curr_tstamp; @@ -1660,8 +1673,10 @@ static int snd_pcm_lib_ioctl_reset(struct snd_pcm_substream *substream, if (snd_pcm_running(substream) && snd_pcm_update_hw_ptr(substream) >= 0) runtime->status->hw_ptr %= runtime->buffer_size; - else + else { runtime->status->hw_ptr = 0; + runtime->hw_ptr_wrap = 0; + } snd_pcm_stream_unlock_irqrestore(substream, flags); return 0; } -- 1.7.9.5

2 5

[alsa-devel] [PATCH 0/2] USB-audio disconnection race fixes (v2)
by Takashi Iwai 19 Oct '12

19 Oct '12

Hi, this is a series of fixes for the disconnection races in USB-audio. A couple of new patches to improve and cover more points since the previous patch set. Takashi

1 7

Re: [alsa-devel] [PATCH v2 1/1] ALSA: hda - add quirk for Thinkpad T430
by Jonathan Nieder 19 Oct '12

19 Oct '12

joseph.salisbury(a)canonical.com wrote: > This patch adds a quirk to enable headphone jack audio on T430 Thinkpads. > > Signed-off-by: Joseph Salisbury <joseph.salisbury(a)canonical.com> > Cc: <stable(a)vger.kernel.org> Thanks --- this is a little better. One more nit: it looks like this was reported, tested, and based on a patch by Stefan Freyr. Takashi, could you amend the message to reflect that, or should the patch be resent? Something like -- >8 -- From: Stefán Freyr <stefan.freyr(a)gmail.com> Subject: ALSA: hda - add dock support for Thinkpad T430 I have a Lenovo ThinkPad T430 and an UltraBase Series 3 docking station. Without this patch, if I plug my headphones into the jack on the computer, everything works fine. The computer speakers mute and the audio is played in the headphones. However, if I plug into the docking station headphone jack the computer speakers are muted but there is no audio in the headphones. Addresses https://bugs.launchpad.net/bugs/1060372 Signed-off-by: Joseph Salisbury <joseph.salisbury(a)canonical.com> Cc: stable(a)vger.kernel.org

2 1

[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

Re: [alsa-devel] [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430
by Jonathan Nieder 19 Oct '12

19 Oct '12

Hi Joseph, joseph.salisbury(a)canonical.com wrote: > [Subject: [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430]] [...] > This patch is to enable audio on T430 Thinkpads. There is no audo > from the headphone jack without this patch. This patch adds a quirk > for the T430 model. Please don't do this cover-letter thing. A cover letter can be a good way to *summarize* a long patch series so readers are less daunted, but any information that was needed to know in order to evaluate a patch, briefly stated, should be in the commit message that actually gets committed. Thanks and hope that helps, Jonathan

1 0

[alsa-devel] Non-interleaved with plughw
by Prasant J 19 Oct '12

19 Oct '12

Hi, My hardware supports only interleaved access and I'm recording and playing using hw:0,0. Currently I provide interleaved buffers to the device. What I read is that plughw device can convert non-interleaved buffers to interleave buffers before sending to hardware. I want to reduce complexity of my application and want to use plughw. But I'm not able to get good documentation or examples of the same. Can anyone point out to me? Regards, -Prasant

1 1

Re: [alsa-devel] ASoC: mmap or read/write?
by Mike Looijmans 19 Oct '12

19 Oct '12

Clemens ------------------------------ Message: 6 Date: Thu, 18 Oct 2012 15:07:45 +0530 From: Prasant J <pj0585(a)gmail.com> To: Clemens Ladisch <clemens(a)ladisch.de> Cc: alsa-devel(a)alsa-project.org Subject: Re: [alsa-devel] ASoC: mmap or read/write? Message-ID: <CAA2DH4v4DUxf5Qh79nehTPD+22v6XddzDrEMmnBu2eM8m4JXzg(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 18, 2012 at 2:39 PM, Clemens Ladisch <clemens(a)ladisch.de> wrote: >> Prasant J wrote: >>> I'm writing an alsa application for recording & playing 16 channel audio. >>> >>> The application is intended to run on an embedded platform & the >>> resources are highly constrained. >> Then I wonder how you manage to handle 16 channels. >> What hardware is this? > I'm working with Beaglebone (ARM Cortex-A8 720 MHz). (Currently > failures are for 8 channels 32 bit / 16 bit, but our final target is > 16 channels) > >>> My application is not performing well with read/write methods. >> How much CPU usage? > The CPU usage is around 35% (as seen in top) > > I have managed to get Audio capture working fine (after certain linux > optimizations) but playback is giving under-runs (only when PLAYBACK & > CAPTURE run together) > I was wondering that changing access method to mmap (currently I'm > using read/write) may give me some more CPU time. You must be doing something wrong. I'm doing 32-bit, 16-channel input at 51.2kHz on a OMAP-L138 (an ARM9 CPU at 450 MHz) under Linux and it's using no more than 25% CPU for that. Just using"arecord" for that. Mike. (sorry for the company sig) Met vriendelijke groet / kind regards, Mike Looijmans TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) – (0)499 - 33.69.79 Telefax: (+31) - (0)499 - 33.69.70 E-mail: mike.looijmans(a)topic.nl Website: www.topic.nl Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen. The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.

3 3

[alsa-devel] Kernel panic with SB Live (snd_emu10k1) when sharing interrupts
by John Paul Adrian Glaubitz 19 Oct '12

19 Oct '12

Hello, I have a Creative SoundBlaster Live! PCI (PCI-IDs: 1102:0002 and 1102:7002) which I recently ran into trouble with. I used the SB Live! to replace my SB128 PCI which ran fine in the configuration (ASUS P8B-C/4L, see attached output from dmesg and lspci). Once I swapped the sound cards, I booted up the machine and immediately ran into a kernel panic [1] which seems to indicate that there is a problem with interrupt sharing. I there removed the Firewire card which was placed adjacent to the SB Live and the machine ran stable again. I assume that the snd_emu10k1 driver is sometimes not handling shared interrupts properly, isn't it? I wanted to report this as a bug in the ALSA bug tracker [2], but alas the tracker is currently down. I'm attaching the output of dmesg [3] as well as lspci [4]. Will provide more information if requested. Cheers, Adrian > [1] http://users.physik.fu-berlin.de/~glaubitz/emu10k1_panic.jpg > [2] https://bugtrack.alsa-project.org/alsa-bug/ > [3] http://users.physik.fu-berlin.de/~glaubitz/dmesg_emu10k1.txt > [4] http://users.physik.fu-berlin.de/~glaubitz/lspci_emu10k1.txt

2 1

[alsa-devel] [PATCH v2 0/2] ASoC: omap-mcpdm updates for 3.7
by Peter Ujfalusi 19 Oct '12

19 Oct '12

Hello Mark, Tony, Change since v1: - Fixed the second patch to keep the omap_mcpdm_open_stream() - after a coffee The mcpdm driver no longer needs to include any plat/*.h file, clearing the way for the single kernel image. Regards, Peter --- Peter Ujfalusi (1): ASoC: omap-mcpdm: Remove OMAP revision check Tony Lindgren (1): ASoC: Fix wrong include for McPDM sound/soc/omap/omap-mcpdm.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) -- 1.7.12

3 10