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

Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
by Jussi Laako 06 Apr '13

06 Apr '13

On 04/05/2013 10:59 PM, Andreas Koch wrote: > However, they are interpreting the ASIO spec for DSD differently. They > express buffer size in samples, which means that for DSD it is measured > in bits. That's how pretty much everybody, including Sony who co-authored the spec, has been interpreting it so far... Otherwise all the latency calculations become inconsistent and need special exceptions for DSD. I agree the ASIO spec is not very clear, however it always talks about number of samples and then specifically mentions that DSD samples are _packed_ into bytes and thus all buffer sizes have to multiples of eight. I have a hidden configuration flag to flip that either way as necessary, but default is that sizes are in _bits_. - Jussi

2 5

[alsa-devel] [PATCH v2 1/2] alsa-lib: pcm.c: fix indentation
by Daniel Mack 06 Apr '13

06 Apr '13

Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- src/pcm/pcm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 05737d9..2963711 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -1634,11 +1634,11 @@ static const char *const snd_pcm_type_names[] = { PCMTYPE(LADSPA), PCMTYPE(DMIX), PCMTYPE(JACK), - PCMTYPE(DSNOOP), - PCMTYPE(IEC958), + PCMTYPE(DSNOOP), + PCMTYPE(IEC958), PCMTYPE(SOFTVOL), - PCMTYPE(IOPLUG), - PCMTYPE(EXTPLUG), + PCMTYPE(IOPLUG), + PCMTYPE(EXTPLUG), PCMTYPE(MMAP_EMUL), }; -- 1.8.1.4

1 1

[alsa-devel] got a segmentation fault when use multi-channel device
by Zhang wei 06 Apr '13

06 Apr '13

hello everone. i am now debuging the multi-channel device on my embeded board with alsa-lib.The version alsa-driver and alsa-lib is 1.0.24. -----------------------------> zz@board:$ ls /dev/snd/ by-path controlC0 midiC0D0 pcmC0D0c pcmC0D0p pcmC0D1p seq timer <--------------------------- i edit the asoundrc configure file.like this: ---------------------------------------------------> pcm.!default{ type hw card 0 } ctl.!default{ type hw card 0 } ################################# ## create a virtul device which has 4 channels for playback. ################################# pcm.multi_playback{ type multi; slaves.a.pcm "hw:0,0"; slaves.a.channels 2; slaves.b.pcm "hw:0,1"; slaves.b.channels 2; bindings.0.slave a; bindings.0.channel 0; bindings.1.slave a; bindings.1.channel 1; bindings.2.slave b; bindings.2.channel 0; bindings.3.slave b; bindings.3.channel 1; } ctl.multi_playback{ type hw; card 0; } pcm.ttable{ type route; slave.pcm "multi_playback"; slave.channels 4; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; } ctl.ttable { type hw; card 0; } <-------------------------------------------------- and then get the Segmentation fault: --------------------------------------------------------------> [root@board /tmp]#./pb_pcm_min open...ver:[0.71] playback...capture...device=[multi_playback] #####################snd_pcm_open... zz[snd_dlsym_verify:122],vname=[_snd_config_hook_load_dlsym_config_hook_ 001] zz[snd_dlsym_verify:127] zz[snd_dlsym:167] zz[snd_dlsym:171],name=[snd_config_hook_load] zz[snd_pcm_open_conf:2163] zz[snd_dlsym_verify:122],vname=[__snd_pcm_multi_open_dlsym_pcm_001] Segmentation fault [root@board /tmp]# <--------------------------------------------------------------- To my surpris, it will be fine when run on the PC under the Ubuntu system.I used the same alsa-lib source code and the configure file asoundrc. in my codec-driver .i have not call the functions :snd_soc_add_controls() / snd_soc_dapm_new_controls() / snd_soc_dapm_add_routes(). is it the reason? But the programm have not arrived here. i have traced the source code when the Segmentation fault happened the alsa-lib was calling the function dlysm() with the param vname=__snd_pcm_multi_open_dlsym_pcm_001. But this will not happen on my PC under Ubuntu. could you help me find out what's wrong with me? thanks a lot. zw

1 0

[alsa-devel] PROBLEM: very loud sound of electric discharge on shutdown and restart with ALC882M with all kernels I tried up to 3.9 rc5
by Jenya Y 06 Apr '13

06 Apr '13

I always had this problem in linux and only today tried to search for answers. Solutions I came across involved disabling power management on Intel HDA, which is already 0 by default and also the option of muting on shutdown/ restart, which had absolutely no effect. I wish I could figure this out myself but after 4 hours of searching and trying things out and countless restarts I've given up and decided to come to you for help. Jenya On 03/20/2013 08:41 AM, Jenya Y wrote: > I still didn't receive anything from you as I already mentioned I tried > most of the 'obvious' solutions I came accross and still looking for > answers. > Maybe I'm using the wrong ML for this question. If so, maybe you could at > least suggest another HDA/ ALSA maintainer to contact in this situation. > > TIA, Jenya.

1 0

[alsa-devel] [PATCH v2] ALSA: hda/ca0132 - Update latency based on DSP state.
by Dylan Reid 05 Apr '13

05 Apr '13

The DSP in the CA0132 codec adds a variable latency to audio depending on what processing is being done. Add a new patch op to return that latency for capture and playback streams. The latency is determined by which blocks are enabled and knowing how much latency is added by each block. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- Changes since v1: Rebase on tiwai's patch to add a pcm_op, this is dependent on that. Get ms to frames conversion right. Test loopback and compare measured vs reported latency. sound/pci/hda/patch_ca0132.c | 55 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 53 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 12eb21a..841842c 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -131,6 +131,13 @@ enum { /* Effects values size*/ #define EFFECT_VALS_MAX_COUNT 12 +/* Latency introduced by DSP blocks in milliseconds. */ +#define DSP_CAPTURE_INIT_LATENCY 0 +#define DSP_CRYSTAL_VOICE_LATENCY 124 +#define DSP_PLAYBACK_INIT_LATENCY 13 +#define DSP_PLAY_ENHANCEMENT_LATENCY 30 +#define DSP_SPEAKER_OUT_LATENCY 7 + struct ct_effect { char name[44]; hda_nid_t nid; @@ -2743,6 +2750,31 @@ static int ca0132_playback_pcm_cleanup(struct hda_pcm_stream *hinfo, return 0; } +static unsigned int ca0132_playback_pcm_delay(struct hda_pcm_stream *info, + struct hda_codec *codec, + struct snd_pcm_substream *substream) +{ + struct ca0132_spec *spec = codec->spec; + unsigned int latency = DSP_PLAYBACK_INIT_LATENCY; + struct snd_pcm_runtime *runtime = substream->runtime; + + if (spec->dsp_state != DSP_DOWNLOADED) + return 0; + + /* Add latency if playback enhancement and either effect is enabled. */ + if (spec->effects_switch[PLAY_ENHANCEMENT - EFFECT_START_NID]) { + if ((spec->effects_switch[SURROUND - EFFECT_START_NID]) || + (spec->effects_switch[DIALOG_PLUS - EFFECT_START_NID])) + latency += DSP_PLAY_ENHANCEMENT_LATENCY; + } + + /* Applying Speaker EQ adds latency as well. */ + if (spec->cur_out_type == SPEAKER_OUT) + latency += DSP_SPEAKER_OUT_LATENCY; + + return (latency * runtime->rate) / 1000; +} + /* * Digital out */ @@ -2811,6 +2843,23 @@ static int ca0132_capture_pcm_cleanup(struct hda_pcm_stream *hinfo, return 0; } +static unsigned int ca0132_capture_pcm_delay(struct hda_pcm_stream *info, + struct hda_codec *codec, + struct snd_pcm_substream *substream) +{ + struct ca0132_spec *spec = codec->spec; + unsigned int latency = DSP_CAPTURE_INIT_LATENCY; + struct snd_pcm_runtime *runtime = substream->runtime; + + if (spec->dsp_state != DSP_DOWNLOADED) + return 0; + + if (spec->effects_switch[CRYSTAL_VOICE - EFFECT_START_NID]) + latency += DSP_CRYSTAL_VOICE_LATENCY; + + return (latency * runtime->rate) / 1000; +} + /* * Controls stuffs. */ @@ -4002,7 +4051,8 @@ static struct hda_pcm_stream ca0132_pcm_analog_playback = { .channels_max = 6, .ops = { .prepare = ca0132_playback_pcm_prepare, - .cleanup = ca0132_playback_pcm_cleanup + .cleanup = ca0132_playback_pcm_cleanup, + .get_delay = ca0132_playback_pcm_delay, }, }; @@ -4012,7 +4062,8 @@ static struct hda_pcm_stream ca0132_pcm_analog_capture = { .channels_max = 2, .ops = { .prepare = ca0132_capture_pcm_prepare, - .cleanup = ca0132_capture_pcm_cleanup + .cleanup = ca0132_capture_pcm_cleanup, + .get_delay = ca0132_capture_pcm_delay, }, }; -- 1.8.1.5

3 9

[alsa-devel] [PATCH 00/10] UAC2: Automatic clock switching
by Eldad Zack 05 Apr '13

05 Apr '13

Hi, This patch series is intended for-next. It provides automatic clock switching for UAC2 devices (patches #6-#8). If the current selected clock is not valid, other clocks will be checked and the first (indexwise) valid clock will be used. Patch #8 provides a module flag to turn this logic off, since in some use cases (e.g., studio work) it might not be desired. But I think most users want their audio devices to "just work", so the default is on. To make the change more obvious, I first moved the validity check around without changing any logic (#6). Patch #10 adds support for clocks with read-only sample frequency control. All other patches included are trivial clean up patches. I'd appreciate a review and/or testing this patch series. This applies to all UAC2 devices, so please let me know if anyone sees any issue. Tested with mainline. Applies against mainline (3.9-rc4), HEAD at 46a1f21a679abaaeae6db9969963dc998c9f1c1c Applies against Takashi's for-next, HEAD at 4abdbd1c2c1832e7270e546307ffb3e56b286db2 Cheers, Eldad Zack (10): ALSA: usb-audio: convert list_for_each to entry variant ALSA: usb-audio: neaten MODULE_DEVICE_TABLE placement ALSA: usb-audio: neaten EXPORT_SYMBOLS placement ALSA: usb-audio: spelling correction ALSA: usb-audio: use endianness macros ALSA: usb-audio: UAC2: do clock validity check earlier ALSA: usb-audio: UAC2: try to find and switch to valid clock ALSA: usb-audio: UAC2: auto clock selection module param ALSA: usb-audio: show err in set_sample_rate_v2 debug ALSA: usb-audio: UAC2: support read-only freq control sound/usb/card.c | 11 ++-- sound/usb/clock.c | 150 ++++++++++++++++++++++++++++++++++++++------------- sound/usb/clock.h | 3 +- sound/usb/endpoint.c | 18 +++---- sound/usb/endpoint.h | 2 +- sound/usb/format.c | 2 +- sound/usb/midi.c | 12 ++--- sound/usb/pcm.c | 32 ++++------- sound/usb/proc.c | 7 ++- sound/usb/stream.c | 12 ++--- sound/usb/usbaudio.h | 1 + 11 files changed, 155 insertions(+), 95 deletions(-) -- 1.8.1.5

4 23

Re: [alsa-devel] Deadlock over semaphore issue with aplay while using dmix
by mateen 05 Apr '13

05 Apr '13

Hi, I checked with Takshi's patch and would like to suggest couple of changes. 1. We keep dmix_down_sem(dmix) and dmix_up_sem(dmix) as macros instead of defining them as functions. 2. We free up the semaphore in snd_pcm_dmix_close() if it is recognized that the semaphore is held up by the same process, which will be indicated by dmix->semlocked flag. Mateen. diff -Nuar dir2/pcm_direct.h dir1/pcm_direct.h --- dir2/pcm_direct.h 2009-12-16 20:48:51.000000000 +0530 +++ dir1/pcm_direct.h 2013-04-05 17:06:48.331497000 +0530 @@ -123,6 +123,7 @@ int ipc_gid; /* IPC socket gid */ int semid; /* IPC global semaphore identification */ int shmid; /* IPC global shared memory identification */ + int semlocked; snd_pcm_direct_share_t *shmptr; /* pointer to shared memory area */ snd_pcm_t *spcm; /* slave PCM handle */ snd_pcm_uframes_t appl_ptr; diff -Nuar dir2/pcm_dmix.c dir1/pcm_dmix.c --- dir2/pcm_dmix.c 2009-12-16 20:48:51.000000000 +0530 +++ dir1/pcm_dmix.c 2013-04-05 17:04:02.781109000 +0530 @@ -285,8 +285,17 @@ */ #ifndef DOC_HIDDEN #ifdef NO_CONCURRENT_ACCESS -#define dmix_down_sem(dmix) snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT) -#define dmix_up_sem(dmix) snd_pcm_direct_semaphore_up(dmix, DIRECT_IPC_SEM_CLIENT) +#define dmix_down_sem(dmix) \ +{\ +if (!dmix->semlocked++)\ + snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT);\ +} +#define dmix_up_sem(dmix) \ +{\ + if (!--dmix->semlocked)\ + snd_pcm_direct_semaphore_up(dmix, DIRECT_IPC_SEM_CLIENT);\ +} + #else #define dmix_down_sem(dmix) #define dmix_up_sem(dmix) @@ -764,7 +773,13 @@ if (dmix->timer) snd_timer_close(dmix->timer); - snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT); + if(!dmix->semlocked) + snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT); + else{ + snd_pcm_direct_semaphore_up(dmix, DIRECT_IPC_SEM_CLIENT); + snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT); + } + snd_pcm_close(dmix->spcm); if (dmix->server) snd_pcm_direct_server_discard(dmix); ------------------------------ ---------------------------------------- Message: 1 Date: Thu, 04 Apr 2013 18:30:01 +0200 From: Takashi Iwai <tiwai(a)suse.de> To: Jaroslav Kysela <perex(a)perex.cz> Cc: alsa-devel(a)alsa-project.org Subject: Re: [alsa-devel] Deadlock over semaphore issue with aplay while using dmix Message-ID: <s5h38v645ti.wl%tiwai(a)suse.de> Content-Type: text/plain; charset=US-ASCII At Thu, 04 Apr 2013 13:33:08 +0200, Jaroslav Kysela wrote: > > Date 4.4.2013 11:27, mateen wrote: > > Hi, > > > > I seeing sometimes deadlock issue with dmix when I press CTRL+C. > > > > Aplay's signal handler calls snd_pcm_close() if an interrupt occurs. > > snd_pcm_close() will internally call pcm->ops->close() which will fall to > > snd_pcm_dmix_close() in case you are using dmix. > > > > snd_pcm_dmix_close() will try to acquire the semaphore with > > snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT). > > The same semaphore is acquired in snd_pcm_dmix_sync_area() with > > dmix_down_sem() in case of non-concurrent access. > > > > If semaphore is acquired in snd_pcm_dmix_sync_area() which is in thread > > context and interrupt comes, which invokes the signal handler which is in > > ISR context, which calls snd_pcm_close() which in turn calls > > snd_pcm_dmix_close() then we see a deadlock since semaphore is not released > > from thread context and ISR is waiting indefinitely on the same semaphore. > > > > Please suggest a suitable solution for this. > > It seems that also other configurations (alsa-lib plugins) have trouble > with the closing from the signal handler - I hit mutex issues with the > PulseAudio plugin, too. > > The question is, how we can do a clean path in this case. Looking to the > current alsa-lib code, I would suggest to add the snd_pcm_abort() > function (may be called from the interrupt handler) to notify the > library to not ignore -EINTR return codes from poll() and other i/o ops > and pass it to the caller (application) to finish the normal close sequence. > > Opinions? Isn't it only about the direct plugins with the case where no coherent memory is available? If so, we may just avoid the deadlock by checking some internal flag like the patch below (untested)? It's no perfect but just some proof, of course. Takashi -- Regards, Shaikh Mateen S. 09423350444

2 2

[alsa-devel] Deadlock over semaphore issue with aplay while using dmix
by mateen 05 Apr '13

05 Apr '13

Hi, I seeing sometimes deadlock issue with dmix when I press CTRL+C. Aplay's signal handler calls snd_pcm_close() if an interrupt occurs. snd_pcm_close() will internally call pcm->ops->close() which will fall to snd_pcm_dmix_close() in case you are using dmix. snd_pcm_dmix_close() will try to acquire the semaphore with snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT). The same semaphore is acquired in snd_pcm_dmix_sync_area() with dmix_down_sem() in case of non-concurrent access. If semaphore is acquired in snd_pcm_dmix_sync_area() which is in thread context and interrupt comes, which invokes the signal handler which is in ISR context, which calls snd_pcm_close() which in turn calls snd_pcm_dmix_close() then we see a deadlock since semaphore is not released from thread context and ISR is waiting indefinitely on the same semaphore. Please suggest a suitable solution for this. -- Regards, Shaikh Mateen S. 09423350444

3 6

[alsa-devel] [PATCH v6 1/2] ALSA: ASoC: davinci-mcasp: don't configure AFSX direction in DIT mode
by yegorslists＠googlemail.com 05 Apr '13

05 Apr '13

From: Yegor Yefremov <yegorslists(a)googlemail.com> AFSX won't be used in DIT mode. The related pins are AHCLKX and the data pins. Signed-off-by: Yegor Yefremov <yegorslists(a)googlemail.com> Acked-by: Vaibhav Bedia <vaibhav.bedia(a)ti.com> Tested-by: Daniel Mack <zonque(a)gmail.com> --- v6: CC Mark Brown v5: add Daniel's Tested-by v4: change subjuct to include "ALSA: ASoC: " sound/soc/davinci/davinci-mcasp.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 9321e5c..90a9b99 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -772,9 +772,6 @@ static void davinci_hw_param(struct davinci_audio_dev *dev, int stream) /* S/PDIF */ static void davinci_hw_dit_param(struct davinci_audio_dev *dev) { - /* Set the PDIR for Serialiser as output */ - mcasp_set_bits(dev->base + DAVINCI_MCASP_PDIR_REG, AFSX); - /* TXMASK for 24 bits */ mcasp_set_reg(dev->base + DAVINCI_MCASP_TXMASK_REG, 0x00FFFFFF); -- 1.7.7

2 2

Re: [alsa-devel] [PATCH 2/2] alsa-lib: bring pcm.h and pcm.c in sync with the kernel list
by Daniel Mack 05 Apr '13

05 Apr '13

Hi Andreas, On 28.03.2013 05:58, Andreas Koch wrote: >> Am I right to assume that in your case it's the same as for DoP, >> IOW, oldest in MSB? > > Good point - thanks for bringing it up - another can of worms. > With Windows having a little endian philosophy we started early on > with the first DSD workstation by putting the oldest sample in the > LSB position. ASIO came along and adopted the same thing, but then > extended support for the opposite as well. Rigisystems (offering OEM > modules for USB audio) came along about a year ago and insisted that > there is only their way, i.e. putting the oldest bit in the MSB > position. I tried to explain to them that there are already hundreds > of products out in the market that do it differently, but that didn't > matter to them. The result is that now we have implementations with > both. Up until now that was not a huge issue, because there is no > generic Windows driver and every hardware manufacturer had to have a > custom driver. > Now of course, with your heroic effort in creating a generic driver > that would help everyone, we have a mess. Some DACs expect little > endian (mine and others as well) and others (all that are based on > Rigisystems modules) big endian positions. > > Since the time I had the discussions with Rigisystems I didn't have > any further communication with them. Maybe it is a good idea to touch > base with them again and find out what the latest is. I will try my > contact there and let you know. Did you hear back from them yet? Do you think we should allocate types for Big Endian DOP formats? Thanks, Daniel

1 0