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

[alsa-devel] [PATCH] Return hw error directly from oustream_write.
by linux＠audioscience.com 28 Aug '10

28 Aug '10

From: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> If hw error is ignored, status is updated with invalid info. Signed-off-by: Eliot Blennerhassett <eblennerhassett(a)audioscience.com> --- sound/pci/asihpi/hpi6205.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/pci/asihpi/hpi6205.c b/sound/pci/asihpi/hpi6205.c index 3b44134..22c5fc6 100644 --- a/sound/pci/asihpi/hpi6205.c +++ b/sound/pci/asihpi/hpi6205.c @@ -941,8 +941,7 @@ static void outstream_host_buffer_free(struct hpi_adapter_obj *pao, } -static u32 outstream_get_space_available(struct hpi_hostbuffer_status - *status) +static u32 outstream_get_space_available(struct hpi_hostbuffer_status *status) { return status->size_in_bytes - (status->host_index - status->dSP_index); @@ -987,6 +986,10 @@ static void outstream_write(struct hpi_adapter_obj *pao, /* write it */ phm->function = HPI_OSTREAM_WRITE; hw_message(pao, phm, phr); + + if (phr->error) + return; + /* update status information that the DSP would typically * update (and will update next time the DSP * buffer update task reads data from the host BBM buffer) -- 1.7.0.4

2 1

[alsa-devel] ASoC update for 2.6.36
by Mark Brown 28 Aug '10

28 Aug '10

The following changes since commit 70bf043b137aa9ff2711b16532774465e07a8f47: ASoC: i.MX ssi: use SSI_STCCR in synchronous mode (2010-08-23 13:33:05 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.36 Axel Lin (1): ASoC: soc-core: fix debugfs_pop_time file permissions You can't get much smaller and less invasive than a one character fix! sound/soc/soc-core.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

2 1

[alsa-devel] [PATCH 0/4] ASoC: tlv320aic3x: Output stage cleanup
by Jarkko Nikula 28 Aug '10

28 Aug '10

Hi I have had always difficulties to remember which aic3x mixer control controls what route but haven't bothered to look any deeper until very recently after wondering why the swapped routes aren't working. It turned out that there were two reasons: 1. Output mixers were misdefined to mix output pins to internal signals where DAPM logic and hw as well does opposite 2. Swapped routes are not working due this misdefinition Then there wasn't uniform way to represent and name volume controls for those output mixer stages. This patchset does first some minor cleanups, then fixes the mixer stage also adding a few missing routes and then puts hopefully some logic to output controls. Unfortunately this means control name changes but hopefully driver is now more understandable and complete. -- Jarkko

3 9

Re: [alsa-devel] [PATCH] ASoC: Complete supported clock ratios and rate constraints for wm8741.
by Mark Brown 28 Aug '10

28 Aug '10

On Fri, Aug 27, 2010 at 03:26:27PM +0100, Ian Lartey wrote: > Signed-off-by: Ian Lartey <ian(a)opensource.wolfsonmicro.com> Applied, thanks - but you probably want to remove alsa-devel-request from your address book.

1 0

Re: [alsa-devel] explicit commandline control of speakers vs headphone output
by Eric Holstege 28 Aug '10

28 Aug '10

Thanks, Clemens; How were you able to determine that from the "amixer scontents" output. Although I can't disable *automatic* speaker mute on headphone insertion, can I explicitly unmute them again (e.g. with amixer sset or cset)? If not.... "cat /proc/asound/card*/codec*" says it is the Realtek ALC888. Does this mean I have to somehow patch the kernel sound module file .../linux-source-2.6.*/sound/pci/hda/patch_realtek.c to fix this somehow? Regards -Eric Clemens Ladisch wrote: > Eric Holstege wrote: > >> Simple mixer control ... >> > > It looks as if your codec cannot be configured to disable the automatic > headphone switching. > > > Regards, > Clemens > > >

3 3

[alsa-devel] Problem with underrun on new CS42448 x2 driver
by Adam Rosenberg 28 Aug '10

28 Aug '10

I am trying to write a driver for the Blackfin BF537 processor on a custom board that has two CS42448 CODECs connected to SPORT0. I am using TDM and there are 8 channels per frame on each data line (primary and secondary). My DMA buffer must interleave the data for the two data lines (for a total of 16 channels of data per frame). I have completed all of this and the driver will sometimes work properly but I am having underrun problems. I would like to use snd_async_add_pcm_handler as it is used in the /test/pcm.c example but it seems as though an underrun occurs at regular intervals causing the PCM prepare function to be called again (this results in a tone that sounds good but only for a short time before it stops and then starts again). There is plenty of time for the data to be transferred. I feel as though the driver is not calling snd_pcm_period_elapsed fast enough. At the moment, I call snd_pcm_period_elapsed from within a callback function that occurs every time a DMA period elapse occurs. I have been working on this for quite a while now. Is there someone who can look at the driver code for me or provide detailed information on when ALSA expects to have snd_pcm_period_elapsed get called to avoid an underrun? The other thing that is strange is that I have to explicitly set the period size for aplay to work. For example: aplay --period-size=1024 test.wav which gives me a period time of 21333 but when I use this period time with the /test/pcm.c sample that is provided the tone still does not sound right (although it does seem to improve) I am about ready to bypass ALSA entirely but I hate the idea of breaking from standards (not to mention having to rewrite an entire audio interface). Any help would be greatly appreciated! You can check out the driver here: http://www.alcorn.com/ftp/swap/ami_cs42448.zip Thank you, Adam Adam Rosenberg Software Engineer Alcorn McBride Inc. 3300 South Hiawassee Building 105 Orlando, FL 32835 (407) 296 - 5800 ext. 5490

3 8

[alsa-devel] xine AC3 dropout problem - Please help!
by VDR User 27 Aug '10

27 Aug '10

Hi. Xine seems to have a problem with ac3 audio dropping out frequently, which ruins the ability to watch hdtv for example. I have made a sample which exhibits this problem, which plays just fine in mplayer so I assume that means root causes such as a buggy system scheduler can be ruled out. The sample also plays fine on my main Windows desktop as well. Adjusting things such as engine.buffers.audio_num_buffers in xine's config has no affect. It has been suggested that the problem may be xine not properly handling a stream error. If anyone can and is willing to take a look at this and hopefully resolve the problem once and for all, that would be great. The sample is 20MB so it can't be attached to this post. Until I can find a better place to host the sample, I've temporarily uploaded it to: http://rapidshare.com/files/415479559/xine_ac3_dropout_bug.tar.bz2 System details are: debian testing stable kernel 2.6.35.3 (quiet notsc clocksource=hpet) gcc 4.4.4-8 alsa-base 1.0.23+dfsg-1 alsa-utils 1.0.23-2 xine-lib-1.2 hg r11577 xine-ui hg r3054 VDR-1.7.15 mplayer-nogui 2:1.0~rc3++svn20100804-0.0 I recently tried the notsc and clocksource=hpet kernel options, which also had no affect. I want to reiterate that the dropout problem only occurs in xine. The error I see in the xine log when the dropout occurs is: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed (-32). Best regards, Derek

2 2

Re: [alsa-devel] explicit commandline control of speakers vs headphone output
by Eric Holstege 27 Aug '10

27 Aug '10

Thanks for the info. (FYI, I have a Windtop 2200 All-in-one touchscreen, on which I'm building an appliance with, among other things, VOIP phone and answering machine capability). I want the user to be able to "put the call on speaker" even if the mic/headphone handset is plugged in. Can amixer override this automuting. Is it that the driver just sets the speakers to mute *at the time* the headphone is plugged in, or does it force them mute *so long as* the headphone is plugged in? Or, regarding the pin_configs possibility, I guess I somehow edit /sys/devices/pci0000:00/0000:00:08.0/sound/card0/hwC0D0/init_pin_configs (or maybe user_pin_configs?). Could one point me to documentation on what the bits mean? Mine are: 0x11 0x411111f0 0x12 0x411111f0 0x14 0x01014010 0x15 0x411111f0 0x16 0x99130120 0x17 0x411111f0 0x18 0x01a19850 0x19 0x99a3095f 0x1a 0x411111f0 0x1b 0x99130130 0x1c 0x411111f0 0x1d 0x4004022b 0x1e 0x01451140 0x1f 0x411111f0 Regards -Eric David Henningsson wrote: > 2010-08-27 20:46, Eric Holstege skrev: > >> Thanks, Clemens; >> >> How were you able to determine that from the "amixer scontents" output. >> >> Although I can't disable *automatic* speaker mute on headphone >> insertion, can I explicitly unmute them again (e.g. with amixer sset or >> cset)? >> >> If not.... >> "cat /proc/asound/card*/codec*" says it is the Realtek ALC888. >> Does this mean I have to somehow patch the kernel sound module file >> .../linux-source-2.6.*/sound/pci/hda/patch_realtek.c >> to fix this somehow? >> > > So in the long run, I think it would be better to leave all auto-muting > to userspace. Then stuff like pulseaudio could to advanced decision of > how to handle input events. But that's the long way. > > There are certainly ways to disable auto-muting for Realtek ALC888, look > along the lines of "speaker_automute" and "unsol_event". It is also > possible that you could tweak your user_pin_config to trick your HP out > into a Line Out. That way it won't automute, and you don't have to > recompile your kernel. > > As a side note: The VIA HDA driver, I believe, have an option for > turning automute off. But it also sets "mute" on a misnamed control at > the same time, tricking PA into believing that you want to mute all > output. So PA is "helpful" and mutes everything else as well. :-/ > >

1 0

Re: [alsa-devel] explicit commandline control of speakers vs headphone output
by Eric Holstege 27 Aug '10

27 Aug '10

Thanks, Clemens. Here it is: Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 19 [61%] [-18.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [on] Front Right: Playback [on] Simple mixer control 'Speaker',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [on] Front Right: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 253 [99%] [0.40dB] Front Right: Playback 253 [99%] [0.40dB] Simple mixer control 'Front',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Surround',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Center',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'LFE',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Line',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'CD',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 25 [81%] [3.00dB] [on] Front Right: Playback 25 [81%] [3.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] Front Right: 0 [0%] Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control 'IEC958 Default PCM',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'Beep',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 31 Front Left: Capture 25 [81%] [21.00dB] [on] Front Right: Capture 25 [81%] [21.00dB] [on] Simple mixer control 'Capture',1 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 31 Front Left: Capture 0 [0%] [-16.50dB] [on] Front Right: Capture 0 [0%] [-16.50dB] [on] Simple mixer control 'Channel Mode',0 Capabilities: enum Items: '2ch' '4ch' '6ch' Item0: '2ch' Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Mic' Regards -Eric Clemens Ladisch wrote: > Eric Holstege wrote: > >> My specific sound HW is "nVidia Corporation MCP79 High Definition Audio >> (rev b1)" >> > > This is the HDA controller, which can be combined with any HDA codec, > which actually controls mixing. > > Please show the output of "amixer scontents". > > > Regards, > Clemens > > >

2 1

[alsa-devel] using plug for sample format conversion
by Adam Rosenberg 27 Aug '10

27 Aug '10

>> I am trying to use plug to play audio files that are S16_LE but my >> hardware only supports S32_LE. It is not working. Here is an example >> of the problem using speaker-test. First I use S32_LE and it works as >> expected. I then try S16_LE but it fails. Does this mean the plug >> plugin cannot convert between these sample formats? >> >> Thanks, >> Adam >> > >Please use latest version of speaker-test and alsa-lib. > >and post struct snd_pcm_hardware of you driver > I am using the latest release of uClinux for Blackfin BF537 and do not know how to configure and install the latest version of alsa-lib and alsa-utils. I am starting to understand how struct snd_pcm_hardware is used by the ALSA PCM code but you are correct to assume I may have something wrong. Here is the struct: static struct snd_pcm_hardware ourCS42448PcmHw = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER ), .formats = SNDRV_PCM_FMTBIT_S32_LE, .rates = SNDRV_PCM_RATE_48000, .rate_min = 48000, .rate_max = 48000, .buffer_bytes_max = 32768, .channels_min = 1, .channels_max = 2, .period_bytes_max = 32768, .periods_min = 1, .period_bytes_min = 8, .periods_max = 4096, }; Can you tell me how to configure and install the latest ALSA and whether the snd_pcm_hardware is correct? Thanks, Adam Adam Rosenberg Software Engineer Alcorn McBride Inc. 3300 South Hiawassee Building 105 Orlando, FL 32835 (407) 296 - 5800 ext. 5490

3 3