September 2011 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Status of Zoom R16
by Evan Ta 08 Nov '12

08 Nov '12

Hi, as subj says: can you tell me how the Zoom R16 is doing? The hardware looks nice, but the latest info I can find is a seemingly unresolved failure to work with Alsa as of feb 2010. Thanks, Evan

4 6

[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 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] [PATCH] snd-usb-us122l: Fix missing NULL checks
by Karsten Wiese 27 Apr '12

27 Apr '12

Fix missing NULL checks in usb_stream_hwdep_poll() and usb_stream_hwdep_ioctl(). Wake up poll waiters before returning from usb_stream_hwdep_ioctl(). Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de> Cc: stable(a)kernel.org --- sound/usb/usx2y/us122l.c | 41 ++++++++++++++++++++--------------------- 1 files changed, 20 insertions(+), 21 deletions(-) diff --git a/sound/usb/usx2y/us122l.c b/sound/usb/usx2y/us122l.c index 91bb296..7abda8d 100644 --- a/sound/usb/usx2y/us122l.c +++ b/sound/usb/usx2y/us122l.c @@ -269,29 +269,26 @@ static unsigned int usb_stream_hwdep_poll(struct snd_hwdep *hw, struct file *file, poll_table *wait) { struct us122l *us122l = hw->private_data; - struct usb_stream *s = us122l->sk.s; unsigned *polled; unsigned int mask; poll_wait(file, &us122l->sk.sleep, wait); - switch (s->state) { - case usb_stream_ready: - if (us122l->first == file) - polled = &s->periods_polled; - else - polled = &us122l->second_periods_polled; - if (*polled != s->periods_done) { - *polled = s->periods_done; - mask = POLLIN | POLLOUT | POLLWRNORM; - break; + mask = POLLIN | POLLOUT | POLLWRNORM | POLLERR; + if (mutex_trylock(&us122l->mutex)) { + struct usb_stream *s = us122l->sk.s; + if (s && s->state == usb_stream_ready) { + if (us122l->first == file) + polled = &s->periods_polled; + else + polled = &us122l->second_periods_polled; + if (*polled != s->periods_done) { + *polled = s->periods_done; + mask = POLLIN | POLLOUT | POLLWRNORM; + } else + mask = 0; } - /* Fall through */ - mask = 0; - break; - default: - mask = POLLIN | POLLOUT | POLLWRNORM | POLLERR; - break; + mutex_unlock(&us122l->mutex); } return mask; } @@ -377,6 +374,7 @@ static int usb_stream_hwdep_ioctl(struct snd_hwdep *hw, struct file *file, { struct usb_stream_config *cfg; struct us122l *us122l = hw->private_data; + struct usb_stream *s; unsigned min_period_frames; int err = 0; bool high_speed; @@ -422,18 +420,18 @@ static int usb_stream_hwdep_ioctl(struct snd_hwdep *hw, struct file *file, snd_power_wait(hw->card, SNDRV_CTL_POWER_D0); mutex_lock(&us122l->mutex); + s = us122l->sk.s; if (!us122l->master) us122l->master = file; else if (us122l->master != file) { - if (memcmp(cfg, &us122l->sk.s->cfg, sizeof(*cfg))) { + if (!s || memcmp(cfg, &s->cfg, sizeof(*cfg))) { err = -EIO; goto unlock; } us122l->slave = file; } - if (!us122l->sk.s || - memcmp(cfg, &us122l->sk.s->cfg, sizeof(*cfg)) || - us122l->sk.s->state == usb_stream_xrun) { + if (!s || memcmp(cfg, &s->cfg, sizeof(*cfg)) || + s->state == usb_stream_xrun) { us122l_stop(us122l); if (!us122l_start(us122l, cfg->sample_rate, cfg->period_frames)) err = -EIO; @@ -444,6 +442,7 @@ unlock: mutex_unlock(&us122l->mutex); free: kfree(cfg); + wake_up_all(&us122l->sk.sleep); return err; } -- 1.7.2.3

2 5

Re: [alsa-devel] Port C Out selector , Port E Out selector of ad1988 and ad1988_3stack_dac_nids
by Raymond Yau 10 Mar '12

10 Mar '12

2011/9/16 Takashi Iwai <tiwai(a)suse.de>: > At Fri, 16 Sep 2011 11:59:54 +0800, > Raymond Yau wrote: >> >> 2011/9/12 Takashi Iwai <tiwai(a)suse.de>: >> > At Wed, 31 Aug 2011 11:21:00 +0800, >> > Raymond Yau wrote: >> >> >> >> HDA - Add Headphone Playback Volume control for ad1988/ad1989 >> >> >> >> - use DAC0 instead of DAC1 for Port-A Headphone >> >> - assign 0x03 to spec->multiout.hp_nid except model="6stack-dig-fp" >> > >> > Thanks, applied now. >> > >> > >> > Takashi >> > >> >> while testing the headphone volume control , >> >> I discover that the "Port C Out selector" and "Port E Out Selector" >> (i.e. node 0x31 and 0x32 ) by commit in patch_anlog.c >> >> fd66e0d0591dd12eb0bea1e9f3aa194bb93cebbd >> >> >> >> * AD1988 >> * >> * Output pins and routes >> * >> * Pin Mix Sel DAC >> * port-A 0x11 (mute/hp) <- 0x22 <- 0x37 <- 03/04/06 >> * port-B 0x14 (mute/hp) <- 0x2b <- 0x30 <- 03/04/06 >> * port-C 0x15 (mute) <- 0x2c <- 0x31 <- 05/0a >> * port-D 0x12 (mute/hp) <- 0x29 <- 04 >> * port-E 0x17 (mute/hp) <- 0x26 <- 0x32 <- 05/0a >> >> >> >> The connection list of node 0x31 and 0x32 are different from datasheet >> >> >> Table 10. Audio Widget >> >> 31 Audio selector Selects DAC_2 and DAC_4 for PORT-C >> PORT-E Out Selector >> 32 Audio selector Selects DAC_2 and DAC_4 for PORT-E >> PORT-C In Selector >> >> >> >> Codec: Analog Devices AD1988 >> Address: 0 >> AFG Function Id: 0x1 (unsol 0) >> Vendor Id: 0x11d41988 >> Subsystem Id: 0x104381e1 >> Revision Id: 0x100400 >> >> >> Node 0x31 [Audio Selector] wcaps 0x300101: Stereo >> Connection: 2 >> 0x04* 0x0a >> Node 0x32 [Audio Selector] wcaps 0x300101: Stereo >> Connection: 2 >> 0x05* 0x04 >> >> >> >> is the following patch based on real hardware ? >> >> >> commit 8c7c7b8dd2828b42c1230c6b0235e7d1dcf57e5 >> >> hda-codec - Fix surrounds on 3stack mode of AD1988 > > I don't see this commit id in my tree... > > > Takashi > http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=fd66e0d0591dd12eb… Thu, 17 Nov 2005 14:31:34 +0000 (15:31 +0100) Add AD1988 codec support to hda-codec driver. http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=f8c7c7b8dd282… Thu, 24 Nov 2005 15:17:20 +0000 (16:17 +0100)] Fixed the swapped surround/CLFE on 3stack mode of AD1988. hda-emu codecs/ad1988a -m "3stack" route -a 0x15 Out[0a] -x Sel[31] -- Mix[2c] -> Pin[15] Out[04] -> Sel[31] -- Mix[2c] -> Pin[15] route -a 0x17 Out[04] -> Sel[32] -- Mix[26] -> Pin[17] Out[05] -x Sel[32] -- Mix[26] -> Pin[17]

2 4

[alsa-devel] [PATCH] ALSA: HDA: Remove unconnected PCM devices for Intel HDMI
by David Henningsson 01 Feb '12

01 Feb '12

Since I'm a little new in HDMI land and the patch is non-trivial, I wouldn't mind some comments on this one. Also thanks to Jaroslav who cleared a few things out about the logical and physical devices which helped me figure out what I should do about it :-) Anyway, here's the patch. Some newer chips have more than one HDMI output, but usually not all of them are exposed as physical jacks. Removing the unused PCM devices (as indicated by BIOS in the pin config default) will reduce user confusion as they currently have to choose between several HDMI devices, some of them not working anyway. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

4 14

[alsa-devel] overrun in case of record
by Rajeev kumar 12 Jan '12

12 Jan '12

Hello Mark I am testing my audio driver on spear platform.During recording I am getting two issues. 1. Overrun issue 2. pcm_read error I am using arecord for capturing data. #arecord -f dat > t overrun!!! (at least 32.949 ms long) Overrun issue: The issue is only reproducible if we try to record for more than 40 sec.The strange part is that Instead of overrun condition generated, it will record complete data for 10sec.(This is verified with the number of bytes recorded). So could you please let me know whether this is an error condition or just a warning. pcm_read error: For this I have seen a bug is locked in the bugzila(*Bug 472469* <show_bug.cgi?id=472469> -arecord: input/output error ). and the status is closed saying insufficient data. Could you please let me know what is the meaning of this bug? Is it like, data is not available in the buffer and pcm_read from the user space fails? But why this situation will arise? Best Regards Rajeev

4 15

[alsa-devel] [RFC 0/5] compress: add compress data API to ALSA kernel
by Vinod Koul 23 Dec '11

23 Dec '11

As agreed during the ASoC workshop in May 2011, this set of patches are a proposal from Intel to add a new compressed data interface to ALSA. This proposal builds on the existing Intel solution and the experience gathered over two years with Meego and Android solutions. This proposal is no longer Intel-specific and was generalized with the addition of a basic core; codec-related definitions are based on the vendor-neutral OpenMAX AL standard. The code as is isn't functional and will need low-level hardware-specific drivers and a tighter integration with ALSA and ASoC. The main ideas will be presented during the Linux Plumbers Conference on September 9. Feedback through the mailing list would be greatly appreciated as well. Future versions will include support for capture, mmap, integration with alsa, asoc, dsp etc Support for effects is beyond the scope of this interface. Vinod Koul (5): compress API documentation compress: add compress parameter definations compress: add API header and driver header files compress: add the core file compress: add makefile and kconfig file .../sound/alsa/compress/snd_compress_data.txt | 186 ++++++ include/sound/compress_driver.h | 138 +++++ include/sound/compress_offload.h | 137 +++++ include/sound/snd_compress_params.h | 396 ++++++++++++ sound/Kconfig | 2 + sound/Makefile | 3 +- sound/compress_offload/Kconfig | 12 + sound/compress_offload/Makefile | 3 + sound/compress_offload/core.c | 632 ++++++++++++++++++++ 9 files changed, 1508 insertions(+), 1 deletions(-) create mode 100644 Documentation/sound/alsa/compress/snd_compress_data.txt create mode 100644 include/sound/compress_driver.h create mode 100644 include/sound/compress_offload.h create mode 100644 include/sound/snd_compress_params.h create mode 100644 sound/compress_offload/Kconfig create mode 100644 sound/compress_offload/Makefile create mode 100644 sound/compress_offload/core.c

9 110

[alsa-devel] Clevo P170HM / Sager NP8170 audio
by Andrew Mahone 04 Dec '11

04 Dec '11

This laptop is detected as ALC892 audio (and by the codec ID this seems to be valid), but none of the configurations for it quite match this device. I've been working on documenting the connections with HDA Analyzer. alsa-info output: http://www.alsa-project.org/db/?f=b86e4c6447867fbd129a36d8a63e2f5caa836c52 The laptop has built-in 5.1, and 5.1 or 7.1 output via jacks. DAC NIDs: 0x02 front 0x03 rear 0x04 clfe 0x05 side internal mixers: 0x0c front 0x0d rear 0x0e clfe 0x0f side internal speaker pins: 0x14 front 0x15 "rear" (front of laptop) 0x16 clfe external ports: fixed route: 0x17 side can select any output: 0x18 mic / output 0x1a line-in / output 0x1b headphone I've been experimenting with patch_realtek.c to add the extra DAC NID, and have had some success with a 6-channel mode for the built-in speakers and an 8-channel mode that mutes all internal speakers and sets the jacks up for output. I still need to manually connect pins 0x18, 0x1a, 0x1b to the correct internal mixers for 7.1 to work, and headphone plugin does not mute internal speakers in 5.1 mode. I have not added a plain stereo mode for internal speakers, although it appears that i can probably configure the codec to mix the front channels to center and LFE. Are there any suggestions for what to do next? My current state as a patch against the linux-3.0.y repository is at http://pastie.org/2400649 -- Andrew Mahone andrew DOT mahone AT gmail DOT com Q: How many voters does it take to change a lightbulb? A: None - if voting could change anything they'd make it illegal

3 29

Re: [alsa-devel] [patch][saa7134] do not change mute state for capturing audio
by Mauro Carvalho Chehab 03 Dec '11

03 Dec '11

Em 24-07-2011 14:45, Stas Sergeev escreveu: > 23.07.2011 19:09, Mauro Carvalho Chehab wrote: >> > In this case, it will not be autounmuted after tuning. >> Hard to tell about your solution without seeing a patch. > OK, it turns out the automute code is already there, > but it doesn't work. The driver for some reasons > starts the scan on initialization, finds the carrier: > --- > saa7134[0]/audio: found PAL main sound carrier @ 6.000 MHz [3969/324] > --- > and, because of that, disables the automute. If the > real mute is not enabled at that point, you get the > white noise right away. The automute code works fine. Maybe you have a strong interference at the default tuning frequency, leading into saa7134 miss-detection. For saa7134 driver: 1) There is an audio carrier; 2) an application wants to listen audio; 3) the device is at automute mode. So, when there's an audio carrier, it will unmute the audio at streaming start. The driver is doing the _right_ thing by letting the audio to flow to PA, when it starts the capture. Unfortunately, on your specific device, starting audio capture also enables audio at the audio output pin. So, you're noticing a problem. People with a saa7134 device without alsa stream won't notice it (old devices). People with alsa stream without anything connected to the LINE OUT people aren't noticing it, if PA is not copying the saa7134 PCM IN stream to the sound card PCM out device (the default, for PA). So, only people that has saa7134 with alsa stream that opted to wire the saa7134 device to the sound card, and with a strong interference at the default tunning frequency (400 MHz) would notice a problem. > Since I have no idea why it finds some carrier, I can't > fix that in any way. Or, maybe, not to call the scan > on driver init? What will that break? Analog tuners need to be tuned at the device init on a high frequency according with their datasheets, otherwise the PLL may fail. > Anyway, as long as the automute code is broken, > we should either start fixing it, or fix PA, or fix mplayer... As I always said, the fix should be at PA, as it makes no sense to start capturing at saa7134 without first configuring it. So, or PA should be converted into a V4L2-aware application, in order to properly init the device (with seems to be the wrong approach) or it _SHOULD_NOT_ automatically enable capture on those devices, as this may cause undesired side effects, on the devices that have the capture pin directly wired to the output pin, witch seems to be the case of your device. PS.: it seems that you've removed Lennart/alsa people from the c/c. I'm re-adding them, as I'm expecting a fix from their side. > Dunno. I wonder how come so many bugs left unfixed > for so long, resulting in a white noise to people... You're the first one that reported it, and the code is there for _years_. So, this is not a commonly noticed problem at all. Mauro.

2 15