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

[alsa-devel] Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII
by Lennart Poettering 25 Jun '10

25 Jun '10

Heya, a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa. http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git Just run "make" in a git checkout and then try: $ ./dbverify Aureon51MkII Master 30 200 That will verify the dB data of the "Master" control of the sound card that goes by the id "Aureon51MkII". It will compare the discrete volume steps 30 and 200: first it will play a full amplitude sine wave at mixer volume step 30, and then will change to mixer volume step 200, but attenuate the sine wave in software compensating for the volume change. So once you hear the sine wave attenuated by the hw, and once by the software. If the card's dB data is correct both sines should have the same volume. Now, playing around with this, I could verify what I already mentioned to Jarsolav elsewhere earlier: it seems that particularly USB cards seem to expose invalid dB data (at least all mine do). For example, for the above mentioned Aureon 5.1 it's really *way* off -- if you posess that card just run the line above, and listen to the difference. It's really bad. OTOH the dB data of the HDA cards I own is pretty accurate as it seems, at least I was unable to decide just by listening which sine wave was attenuated by sw, and which by hw. Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards, or if these cards are just crappy and include invalid data? In which case I wonder what we could do about that? The Aureon's dB range already looks suspicous, since both the max and the min dB value are < 0 (-47.69 to -1.97), so maybe we could add some heuristics to filter out data that already looks suspicous? Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

8 93

[alsa-devel] no audio output with TYAN S7025 motherboard and Realtek ALC262
by Bryan Green 20 Jun '10

20 Jun '10

Hi, I have several systems with a TYAN S7025 motherboard and Realtek ALC262 chipset. I have not been able to produce any audio output. Well, that is except for one of the systems: after a variety of tweeks and tests, I got sound working on one system, but I do not know what change enabled sound to start working, and I have not been able to reproduce the effect on the other systems. I have tested with kernels up to 2.6.33, and with ALSA version 1.0.22.1. For a non-working system, 'alsaconf' gives the following output: Unknown hardware: "HDA-Intel" "Realtek ALC262" "HDA:10ec0262,10ec0262,00100202" "0x8086" "0x3a3e" And dmesg gives the following: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel 0000:00:1b.0: irq 89 for MSI/MSI-X HDA Intel 0000:00:1b.0: setting latency timer to 64 hda_codec: ALC262: BIOS auto-probing. autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) hp_outs=0 (0x0/0x0/0x0/0x0/0x0) mono: mono_out=0x0 dig-out=0x1e/0x0 inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x1c, aux=0x0 dig-in=0x1f realtek: No valid SSID, checking pincfg 0x411111f0 for NID 0x1d realtek: Enable default setup for auto mode as fallback input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8 For the working system, the dmesg output is the same except for two lines: autoconfig: line_outs=1 (0x1b/0x0/0x0/0x0/0x0) inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x1c, aux=0x14 Is there a method for tweaking these values on the non-working system to match the working system, to see if that works? I've uploaded the alsa-info output from a non-working system here: http://www.alsa-project.org/db/?f=91057bfc12790688f1d257743e53d5d0ec2ce1e2 I've uploaded the alsa-info output from the working system here: http://www.alsa-project.org/db/?f=198420f14cd0062713636408640636e6d474cf94 Thanks, -bryan

3 5

Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
by Clemens Ladisch 03 Jun '10

03 Jun '10

Frederick V Heitkamp wrote: > Repeatable Hard Crash. > What else do I need to provide? > > [ 5484.995249] WriteControlReg: not written, no change > [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok > [ 5485.070159] Prepare rate=44100 format=2 channels=2 > [ 5485.070161] set_audio_format[14] = 5 > [ 5485.070166] Prepare rate=44100 format=2 channels=2 > [ 5485.070167] set_audio_format[14] = 5 > [ 5485.070003] PREEMPT SMP > ... > [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g] > ... > [ 5485.965788] [<c10041c0>] ? do_divide_error+0x0/0x90 > [ 5485.980619] [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g] > [ 5485.998047] [<c104764e>] ? run_timer_softirq+0x17e/0x2e0 > [ 5486.014175] [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g] > [ 5486.033940] [<c107a5d5>] ? handle_IRQ_event+0x45/0x190 bytes_to_frames() divides by runtime->frame_bits which is not set until after the hw_params callback has succeeded, but the corresponding chip->substream[] entry is set in that callback, by init_engine(). It should probably have been set in the prepare callback. Frederick, please try the patch below. Takashi, is there any reason why the runtime-> fields are initialized after the hw_params callback? Regards, Clemens --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -403,12 +403,6 @@ if (err < 0) goto _error; - if (substream->ops->hw_params != NULL) { - err = substream->ops->hw_params(substream, params); - if (err < 0) - goto _error; - } - runtime->access = params_access(params); runtime->format = params_format(params); runtime->subformat = params_subformat(params); @@ -446,6 +440,13 @@ runtime->boundary *= 2; snd_pcm_timer_resolution_change(substream); + + if (substream->ops->hw_params != NULL) { + err = substream->ops->hw_params(substream, params); + if (err < 0) + goto _error; + } + runtime->status->state = SNDRV_PCM_STATE_SETUP; pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,

6 10

[alsa-devel] usbaudio: Support for USB audio v2.0 devices
by Daniel Mack 27 May '10

27 May '10

Hi, I've been working on support for USB devices compliant to audio class v2.0 and would like to share what I got. First problem is that they literally changed every single descriptor type by adding or removing fields or changing their width, respectively. Even worse, some enum values were dropped and reassigned so their numerical value has a different meaning now. My first step was to clean up most of the existing descriptor parsers by moving away from anonymous byte array access to real structs so we can see which fields we're actually dereferencing. In a second step, I added definitions for the replacement descriptors and use them at appropriate places. The bInterfaceProtocol field must always be set correctly of course, otherwise we'll parse garbage. Other things that have changed from v1.0 to v2.0 are: * The number of streaming interfaces is now reported by a standard interface association descriptor. The old approach using a proprietary descriptor extension is deprecated. * The number of channels per interface is now stored in the AS_GENERAL descriptor (used to be part of the FORMAT_TYPE descriptor). * The list of supported sample rates is no longer stored in a variable length appendix of the FORMAT_TYPE descriptor but is retrieved from the device using a class specific GET_RANGE command. * Supported sample formats are now reported as 32bit bitmap rather than as a fixed value. For now, this is worked around by choosing just one of them. Eventually, the code should propagate the full ability of the device. * A devices needs to have at least one CLOCK_SOURCE descriptor which denotes a clockID that is needed as argument to the class request command. If can have more than one though and the host driver is in charge to choose the right one. There are also new types for clock selectors and sample rate converters that a device might report. This is all unsupported at the moment. We only parse the first CLOCK_SOURCE and take this one. * Many descriptors (format_type, ...) have changed their layout. Handle this by casting the descriptors to the appropriate structs. With the following patches applied, a v2.0 device is recognized and reported as ALSA device. I can even hear at least some kind of music, but the sample rate setting does not yet seem to be correct. Also, the existing mixer code does not work at all for v2.0 devices. This will be quite some work to support that and I fear the whole thing must be reimplemented for v2.0 specifically. For now, I worked around that by not parsing them at all but bailing out very early. However, I would like to make sure the changes I made so far won't cause any regression for v1.0 devices, and so it would be good to see them applied as a preliminary support. I'll continue working on this and send more updates along. Let me know what you think. Thanks, Daniel

5 33

[alsa-devel] safe support for rewind in ALSA
by pl bossart 04 May '10

04 May '10

All, I'd like to reopen a thread on concerns with the current implementation of rewind in ALSA. This was already discussed on the mailing list last year without any progress. (see http://thread.gmane.org/gmane.linux.alsa.devel/65759/focus=65773 and http://article.gmane.org/gmane.linux.alsa.devel/66902) The problem is that snd_pcm_rewind() allows in theory to go back to the next sample to be rendered. This however isn't possible on any existing hardware. DMAs do prefetch samples ahead of time, and output interfaces have FIFOs on top of this. This isn't too bad in the PC world with HDAudio, since the prefetching is limited. However in the embedded space it has become a headache. To reduce power consumption, most of the recent embedded interfaces do embed some local internal memory (5kB for TI's McBSP3, a lot more for others), and we should provide a means for driver developers to set a bound on how much can be rewound safely when power-saving features are enabled. Note that there already are a set of definitions for FIFOs, but they are either obsolete or no one uses them (actually HDAudio makes use of this value internally in azx_dev but doesn't export it). My suggestion would be to add a 'fifo' parameter to the runtime structure (so that it's visible to the core), let the driver developer fill the value in the .open routine, and use this parameter in rewind to prevent rewinding too much. This parameter would include both hardware FIFOs and DMA buffers. Comments welcome. - Pierre

7 41

[alsa-devel] Reforming S3C I2S towards supporting I2Sv4
by Jassi Brar 02 May '10

02 May '10

Hello, I have prepared some patches that debug and modify the behaviour of extant S3C I2S support towards managing I2Sv4 controllers as well. Overall pic... For now the 'new' I2Sv4 CPU driver(s3c64xx-i2s-v4.c) is almost a copy of s3c64xx-i2s.c The driver will evolve as support for more features is added. Minor quirks in otherwise similar controllers are handled by defining a new field(feature) in 'struct s3c_i2sv2_info' that is meant to contain 1-bit flags for absence/presence of such quirks. The header with I2S register map and bit definitions has been copied to where the drivers are(sound/soc/s3c24xx/) since the header has nothing usable for platform code. Also, it will help avoid need for co-ordination between ASoC and S3C ARCH trees. For now, the header regs-s3c2412-iis.h is left intact but rendered useless by making ASoC drivers include the newly copied version of it (sound/soc/s3c24xx/regs-i2s-v2.h) Later the header could be dropped by patches to S3C PLAT tree. The patches apply against 'for-2.6.35' of http://www.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git Regards. Signed-off-by: Jassi Brar <jassi.brar(a)samsung.com>

6 16

[alsa-devel] [PATCH 01/20] ASoC: S3C: I2Sv2: Add missing semicolon
by Jassi Brar 27 Apr '10

27 Apr '10

Add missing semicolon after s3c2412_i2s_delay Signed-off-by: Jassi Brar <jassi.brar(a)samsung.com> --- sound/soc/s3c24xx/s3c-i2s-v2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/s3c24xx/s3c-i2s-v2.c b/sound/soc/s3c24xx/s3c-i2s-v2.c index aa84f4c..8f08508 100644 --- a/sound/soc/s3c24xx/s3c-i2s-v2.c +++ b/sound/soc/s3c24xx/s3c-i2s-v2.c @@ -753,7 +753,7 @@ int s3c_i2sv2_register_dai(struct snd_soc_dai *dai) /* Allow overriding by (for example) IISv4 */ if (!ops->delay) - ops->delay = s3c2412_i2s_delay, + ops->delay = s3c2412_i2s_delay; dai->suspend = s3c2412_i2s_suspend; dai->resume = s3c2412_i2s_resume; -- 1.6.2.5

4 52

[alsa-devel] [PATCH 1/4] pxa: add namespace on ssp
by Haojian Zhuang 17 Apr '10

17 Apr '10

3 6

[alsa-devel] [PATCH 3/4] ASoC: support pxa168 ssp in ASoC
by Haojian Zhuang 12 Apr '10

12 Apr '10

2 1

[alsa-devel] [PATCH]Support MCP89 and GT21x hdmi audio
by Wei Ni 07 Apr '10

07 Apr '10

Hi, Takashi I developed the hdmi audio driver for new chipset MCP89 and GT21x. The new HAD controller and codec support standard HDMI operation. I attached the patch file, please check it. Thanks Wei. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

6 50