June 2010 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Speaker auto-mute doesn't work on ALC269
by David Song 10 Jun '10

10 Jun '10

When a headphone is plugged, I can hear sound from both speaker and headphone. This issue exists on ASUS EeePC S101 and EeePC 1005PE which both have ALC269. I'm testing with the latest kernel. Any regression here?

2 1

Re: [alsa-devel] [PATCH] NUC900: patch for fix build error
by Liam Girdwood 10 Jun '10

10 Jun '10

On Thu, 2010-06-10 at 10:40 +0800, Wan ZongShun wrote: > This patch is to change 'auido.h' to 'audio.h' for > fixing nuc900 alsa driver build error. > > > Signed-off-by: Wan ZongShun <mcuos.com(a)gmail.com> Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

2 1

[alsa-devel] New release of amidicat program, connecting MIDI to stdin/out
by Josh Lehan 10 Jun '10

10 Jun '10

Hello. On the mailing list a few months ago, mentioned a program I had written, then called "midicat". Found out there's another product by that name. So, the new name of the program is "amidicat". The "a" prefix also clarifies that it's an ALSA program. It's a program that connects the ALSA MIDI sequencer to standard input and output. Among other things, this is fun for prototyping quick MIDI one-liners on the command line, such as "echo 903C7F | amidicat" to play Middle C. I have made a new release of the program, which is basically unchanged, except for a few bug fixes (thanks to Valgrind for discovering a minor memory leak). The biggest improvement is that there's now a manual page and a DocBook documentation page. Here's the webpage for amidicat, if interested: http://www.krellan.com/amidicat/ The download is there. Have fun, and thanks for reading this. Josh Lehan

2 2

[alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
by Peter Ujfalusi 10 Jun '10

10 Jun '10

Hello, Changes since RFC v2: - Comments added explaining the changes, and documenting the API in patch2 - In patch5: - Variable names changed in the hw_rule function - hw_rule function got renamed - The snd_pcm_hw_rule_add calls moved so it anly got set on OMAP3 Intro mail from the previous series: This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the _full_ size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP2: McBSP: Change the way how the FIFO is handled OMAP2: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h | 2 + arch/arm/plat-omap/mcbsp.c | 51 ++++++++++----- sound/soc/omap/omap-mcbsp.c | 113 ++++++++++++++++++++++++------- 4 files changed, 129 insertions(+), 47 deletions(-)

5 12

[alsa-devel] External samplerate changes, UAC2 clock topologies
by Daniel Mack 10 Jun '10

10 Jun '10

Hi, when I implemented the basics for parsing the UAC2 clock functions, I came across some principal questions I would like to discuss. As I wrote in the commit log, UAC2 supports a number of clock units which can be combined to complex topologies. The single unit types are - clock sources (can be fixed, variable, programmable and synced to the USB clock) - clock switches, which let the host decide which one out of many input pins appears on its output pin - clock multipliers, which have a numerator and a denominator, and both can be read-only or read-write, respectively A clock source has controls for its frequency and its validity, a clock selector has a control to control its current state, and a clock multiplier has controls for its numerator and denominator The driver is currently able to walk the graph of connected units in order to find CLOCK_SOURCE descriptors as end-leafs. This is mandatory as all requests for sample rate queries have to be sent to this unit type. This raises the first question, as the driver can only know which sample rates are supported in the currently selected combination of selectors. Once the user changes any of them (which is currently already possible as clock selectors are exported as mixer controls), everything can change. And this can even happen while the stream is active, because there's currently no check about whether the clock selector is part of the actively used path. The second issue I see is that a clock can lose its validity. A real-life example is an external S/PDIF connected device which provides a clock and which is suddenly disconnected. Firmwares are expected to notify the host about such cases, and these messages are trivial to dispatch. However, I wonder how the driver should react on this. From a user's perspective, it would be best to just make the driver find another clock path which reports a valid clock source endpoint, changes the sample rate accordingly and continues streaming. There would be a gap in the stream of course, but at least it would not kill the applications or require major exception handling in userspace. I wonder which approaches are actually possible to implement, which details in the ALSA core would need to be extended, and so on. Any oppinions? Has this been done before for any other audio hardware supported by ALSA? Thanks, Daniel

5 6

[alsa-devel] Mixer volume/decibel mapping
by Sebastian H. 10 Jun '10

10 Jun '10

Hello everyone I'm working on an ALSA-Mixer application for C++/Qt4 and stumbled over volume and decibel mapping for sliders. My question: Is there always an 1 to 1 mapping from volume to decibel and vice versa or can there be decibel values in between two volume steps? Regards, Sebastian H.

7 38

[alsa-devel] snd_mixer handle in two threads
by Sebastian H. 09 Jun '10

09 Jun '10

Hello again This is still about the alsamixer-qt4 application I working on. This time I wonder if a snd_mixer_t handle created with snd_mixer_open ( ... ) can be used in two threads concurrently. One thread should be the main Qt4 GUI thread and the second thread should only poll ( ... ) blocking for ALSA events on the shared snd_mixer_t handle in accompany with snd_mixer_poll_descriptors_count ( ... ) snd_mixer_poll_descriptors ( ... ) snd_mixer_poll_descriptors_revents ( ... ) The second thread then will post Qt4 signals to the main thread on occassion. Does this sound feasible? This approach seems neccessary as I want to avoid timed polls and any integration of linux poll() in the Qt4 mail loop seems to boil down to timed polls. Regards, Sebastian H.

1 1

[alsa-devel] Analog Devices AD1984B HP TouchSmart iq504t No Mic Input
by Brandon Ros 09 Jun '10

09 Jun '10

http://www.alsa-project.org/db/?f=053c6a4c3bc19b4992e3c98d0336a375067c8db3 Despite various models used in /etc/modprobe.d/modprobe.conf (touchsmart, auto, laptop, mobile, thinkpad) and various alsamixer settings, I am unable to get input from the two microphones mounted on my monitor as seen in this picture: http://h10025.www1.hp.com/ewfrf-JAVA/Doc/images/c01481326.jpg Playback works fine.

1 0

[alsa-devel] Alsa + PXA + Kernel 2.6.33 resume issue
by Shane Volpe 09 Jun '10

09 Jun '10

I have upgraded an embedded system (PXA270) to the 2.6.33 kernel (from 2.6.23). Now when I run an audio program (ogg123) and put the system into standby then wake the system up the audio does not work (continue playing) after resume until I terminate ogg123 and start again. After restarting ogg123 the audio works fine with out reseting the system or changing anything else on the system. The system is using the UCB1400 AC97 codec and just as added information when the audio is locked up, after resume, the touchscreen on the system still works which is also controlled by the UCB1400 audio codec. I have also tried several other audio players and the results are the same. Has anyone else seen this bug and does anyone have suggestions on further tests to perform to narrow down were the bug may reside? Regards, Shane

1 0

[alsa-devel] Open source UAC2 sound card for UAC2 driver testing
by Alex Lee 09 Jun '10

09 Jun '10

Hi all, We are developing an open source high speed USB sound card. Please see: http://code.google.com/p/sdr-widget/ for details. With the alpha-1 hardware, we are doing development and testing of the UAC2 firmware against the latest alsa driver here. We have already demonstrated 96khz 24bit stereo capture with UAC2 and we will proceed to 192khz soon. Alpha-1 has an ENOB of at least 20 and we hope alpha-2 will have an ENOB of 22 or better. Alpha-2 kits are available for order now. (Note that these are prototype kits for experimenters only.) With both the UAC2 driver and the sound card firmware being open source, we hope to expedite full UAC2 spec compliance. We are already working closely with Daniel Mack on the testing. Alex

2 1