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

[alsa-devel] bugfix for RME HDSPM alsa driver
by ListsAccount 14 Mar '08

14 Mar '08

Hi, I have had the following problem with the RME HDSPM alsa driver: settings of card: Preferred Sync Reference = Word Sample Clock Source = AutoSync and no input plugged in (neither madi nor optical) playing a file (important!) Monitoring the external rate with amixer, the value was jumping between "None" and "48000 kHz". The proc output showed that the sample rate on word clock was still right at 48000 kHz while the external rate was jumping here, too. External rate seems to jump between word clock and madi input select. When "Preferred Sync Reference = Word" is selected, just the word clock rate should be displayed! I fixed the problem with following patch in alsa-driver-1.0.16/alsa-kernel/pci/rme9652/hdspm.c in function hdspm_external_sample_rate() line 668: There was a typo: instead of status2, status was used. 668c668 < (status & HDSPM_SelSyncRef0) == 0) { --- > (status2 & HDSPM_SelSyncRef0) == 0) { (same way as in snd_hdspm_proc_read_madi function line 3123) greetings

1 0

[alsa-devel] Scope of snd_pcm_hw_params_alloca() ?
by Alan Horstmann 14 Mar '08

14 Mar '08

I've spent a couple of days pining this down. snd_pcm_hw_params_alloca() is part of the user API -right? But accomplished as a #define in pcm.h. However if it is called inside a function, and the pointer stored for future use, after leaving the function the allocation seems to have gone, and attempting thereafter to use the pointer to access the hwparams space in another API function results in seg-fault. This seems rather counter-intuitive (ie unexpected) to someone who has no knowledge of the inner workings, but simply uses the API; the allocation disappears without having been specifically free'd or released in any way. I know that calling it globally gets round the problem, but certainly I could do without all the debug needed to discover that. Comments? Alan

2 3

Re: [alsa-devel] Scope of snd_pcm_hw_params_alloca() ?
by Takashi Iwai 14 Mar '08

14 Mar '08

At Thu, 13 Mar 2008 15:41:02 -0300, Aldrin Martoq wrote: > > Hello, > > On Thu, Mar 13, 2008 at 1:44 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Thu, 13 Mar 2008 16:21:51 +0000, > > Alan Horstmann wrote: > > > I've spent a couple of days pining this down. > > > snd_pcm_hw_params_alloca() is part of the user API -right? But accomplished > > > as a #define in pcm.h. > > Because alloca can be used only with a macro due to its nature. > > > However if it is called inside a function, and the pointer stored for future > > > use, after leaving the function the allocation seems to have gone, and > > > attempting thereafter to use the pointer to access the hwparams space in > > > another API function results in seg-fault. > > You should use snd_pcm_hw_params_malloc() instead. *_alloca() from > asoundlib are based in alloca(). From my system man: > > $ man alloca > NAME > alloca - memory allocator > > SYNOPSIS > #include <alloca.h> > > void *alloca(size_t size); > > DESCRIPTION > The alloca() function allocates size bytes of space in the stack frame > of the caller. This temporary space is automatically freed when the > function that called alloca() returns to its caller. > > [..] > > Yup, this is actually very useful in many many many places! Especially in C, that isn't easy to have implicit destructors. BTW, a pitfall once I fell into is that the alloca frees the data at the function exit, not at the block exit. So, the following code eats stack up and shall evetually dies: { ... for (;;) { char *tmp = alloca(4096); ... } ... } Takashi

1 0

[alsa-devel] [PATCH] Map 3stack-6ch-dig ALC662 model for Asus P5GC-MX
by Herton Ronaldo Krzesinski 14 Mar '08

14 Mar '08

Map 3stack-6ch-dig ALC662 model for Asus P5GC-MX. Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com> diff -p -up linux-2.6.24/sound/pci/hda/patch_realtek.c.orig linux-2.6.24/sound/pci/hda/patch_realtek.c --- linux-2.6.24/sound/pci/hda/patch_realtek.c.orig 2008-03-11 16:00:01.000000000 -0300 +++ linux-2.6.24/sound/pci/hda/patch_realtek.c 2008-03-11 16:09:43.000000000 -0300 @@ -13399,6 +13399,7 @@ static const char *alc662_models[ALC662_ }; static struct snd_pci_quirk alc662_cfg_tbl[] = { + SND_PCI_QUIRK(0x1043, 0x8290, "ASUS P5GC-MX", ALC662_3ST_6ch_DIG), SND_PCI_QUIRK(0x1043, 0x82a1, "ASUS Eeepc", ALC662_ASUS_EEEPC_P701), SND_PCI_QUIRK(0x1043, 0x82d1, "ASUS Eeepc EP20", ALC662_ASUS_EEEPC_EP20), SND_PCI_QUIRK(0x17aa, 0x101e, "Lenovo", ALC662_LENOVO_101E), -- []'s Herton

2 1

[alsa-devel] [PATCH 3/5] asihpi: Remove HPI4000
by Eliot Blennerhassett 14 Mar '08

14 Mar '08

Remove HPI4000 Signed-off-by: Eliot Blennerhassett <linux(a)audioscience.com --- diff -r 6def4892d3f5 pci/asihpi/Makefile --- a/pci/asihpi/Makefile Mon Mar 03 11:05:48 2008 +0100 +++ b/pci/asihpi/Makefile Thu Mar 06 14:31:55 2008 +1300 @@ -7,7 +7,7 @@ include $(SND_TOPDIR)/Makefile.conf snd-asihpi-objs := asihpi.o hpimod.o hpimsginit.o\ hpicmn.o hpifunc.o hpidebug.o hpidspcd.o\ - hpios_linux_kernel.o hpi4000.o hpi6000.o hpi6205.o hpimsgx.o + hpios_linux_kernel.o hpi6000.o hpi6205.o hpimsgx.o obj-$(CONFIG_SND_ASIHPI) += snd-asihpi.o diff -r 6def4892d3f5 pci/asihpi/hpimsgx.c --- a/pci/asihpi/hpimsgx.c Mon Mar 03 11:05:48 2008 +0100 +++ b/pci/asihpi/hpimsgx.c Thu Mar 06 12:21:49 2008 +1300 @@ -476,8 +476,6 @@ void HPI_MessageEx( ep_name = "HPI_6000"; else if (ep == HPI_6205) ep_name = "HPI_6205"; - else if (ep == HPI_4000) - ep_name = "HPI_4000"; else ep_name = "unknown"; @@ -598,7 +596,8 @@ static void InStreamClose( if (hOwner == aIStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner) { - /* HPI_DEBUG_LOG(INFO,"closing adapter %d instream %d owned by %p\n", + /* HPI_DEBUG_LOG(INFO,"closing adapter %d " + "instream %d owned by %p\n", phm->wAdapterIndex, phm->u.d.wStreamIndex, hOwner); */ aIStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner = NULL; @@ -701,7 +700,8 @@ static void OutStreamClose( if (hOwner == aOStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner) { - /* HPI_DEBUG_LOG(INFO,"closing adapter %d outstream %d owned by %p\n", + /* HPI_DEBUG_LOG(INFO,"closing adapter %d " + "outstream %d owned by %p\n", phm->wAdapterIndex, phm->u.d.wStreamIndex, hOwner); */ aOStreamUserOpen[phm->wAdapterIndex][phm->u.d.wStreamIndex]. hOwner = NULL; @@ -904,8 +904,9 @@ static u16 HPIMSGX_Init( phr->wError = HPI_ERROR_PROCESSING_MESSAGE; return phr->wError; } - /* if the adapter was created succesfully save the mapping for future use */ if (hr.wError == 0) { + /* the adapter was created succesfully + save the mapping for future use */ hpi_entry_points[hr.u.s.wAdapterIndex] = entry_point_func; /* prepare adapter (pre-open streams etc.) */ HPI_DEBUG_LOG(DEBUG, @@ -936,7 +937,7 @@ static void HPIMSGX_Cleanup( } for (; wAdapter < wAdapterLimit; wAdapter++) { - /* printk(KERN_INFO "Cleanup adapter #%d\n",wAdapter); */ + /* printk(KERN_INFO "Cleanup adapter #%d\n",wAdapter); */ for (i = 0; i < HPI_MAX_STREAMS; i++) { if (hOwner == aOStreamUserOpen[wAdapter][i].hOwner) { struct hpi_message hm; diff -r 6def4892d3f5 pci/asihpi/hpipcida.h --- a/pci/asihpi/hpipcida.h Mon Mar 03 11:05:48 2008 +0100 +++ b/pci/asihpi/hpipcida.h Wed Mar 05 21:59:17 2008 +1300 @@ -34,20 +34,4 @@ HPI_PCI_VENDOR_ID_TI, HPI_ADAPTER_PCI204 HPI_PCI_VENDOR_ID_AUDIOSCIENCE, PCI_ANY_ID, 0, 0, (kernel_ulong_t) HPI_6000} , { -HPI_PCI_VENDOR_ID_MOTOROLA, HPI_ADAPTER_DSP56301, - HPI_PCI_VENDOR_ID_AUDIOSCIENCE, PCI_ANY_ID, 0, 0, - (kernel_ulong_t) HPI_4000} -, - /* look for ASI cards that have 0x12cf sub-vendor ID, - like the 4300 and 4601 */ -{ -HPI_PCI_VENDOR_ID_MOTOROLA, HPI_ADAPTER_DSP56301, 0x12CF, PCI_ANY_ID, - 0, 0, (kernel_ulong_t) HPI_4000} -, - /* look for ASI cards that have sub-vendor-ID = 0, - like the 4501, 4113 and 4215 revC and below */ -{ -HPI_PCI_VENDOR_ID_MOTOROLA, HPI_ADAPTER_DSP56301, 0, PCI_ANY_ID, 0, 0, - (kernel_ulong_t) HPI_4000} -, { 0,}

2 4

[alsa-devel] [PATCH] hda: 92HD73xxx distortion fix
by Matthew Ranostay 14 Mar '08

14 Mar '08

Fixed issue on some laptops that if the Master mixer and DAC mixers are turned all the way up that will cause distortion. This is fixed by limiting the max volume with the volume knob nid. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 547e051a88b5 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Wed Mar 12 13:12:15 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Wed Mar 12 21:48:13 2008 -0400 @@ -526,6 +526,25 @@ static struct hda_verb stac92hd73xx_6ch_ { 0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, { 0x10, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, { 0x11, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, + /* setup import muxs */ + { 0x28, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x29, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x2a, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x2b, AC_VERB_SET_CONNECT_SEL, 0x00}, + {} +}; + +static struct hda_verb dell_eq_core_init[] = { + /* set master volume to max value without distortion + * and direct control */ + { 0x1f, AC_VERB_SET_VOLUME_KNOB_CONTROL, 0xec}, + /* setup audio connections */ + { 0x0d, AC_VERB_SET_CONNECT_SEL, 0x00}, + { 0x0a, AC_VERB_SET_CONNECT_SEL, 0x01}, + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x02}, + /* setup adcs to point to mixer */ + { 0x20, AC_VERB_SET_CONNECT_SEL, 0x0b}, + { 0x21, AC_VERB_SET_CONNECT_SEL, 0x0b}, /* setup import muxs */ { 0x28, AC_VERB_SET_CONNECT_SEL, 0x01}, { 0x29, AC_VERB_SET_CONNECT_SEL, 0x01}, @@ -3460,17 +3479,19 @@ again: switch (spec->board_config) { case STAC_DELL_M6: - spec->init = dell_m6_core_init; + spec->init = dell_eq_core_init; switch (codec->subsystem_id) { case 0x1028025e: /* Analog Mics */ case 0x1028025f: stac92xx_set_config_reg(codec, 0x0b, 0x90A70170); spec->num_dmics = 0; break; - case 0x10280254: /* Digital Mics */ + case 0x10280271: /* Digital Mics */ + case 0x10280272: + spec->init = dell_m6_core_init; + /* fall-through */ + case 0x10280254: case 0x10280255: - case 0x10280271: - case 0x10280272: stac92xx_set_config_reg(codec, 0x13, 0x90A60160); spec->num_dmics = 1; break;

2 1

[alsa-devel] alsa conf file
by tomars 14 Mar '08

14 Mar '08

I write a asound.conf file in the /etc/ , the detail is as follows. pcm.hardware{ type hw:0 card 0 device 0 } pcm_slave.test { pcm "hardware" format S16_LE rate 44100 channels 2 period_time 20000 buffer_time 80000 } pcm.mix1{ type dmix ipc_key 1235675 ipc_key_add_uid true slave "test" } pcm.mix2{ type dmix ipc_key 1235675 ipc_key_add_uid true slave { pcm "hw:0" format S16_LE rate 44100 channels 2 period_time 20000 buffer_time 80000 } } pcm.!default { type plug slave.pcm mix2 #slave.pcm mix1 } when I use the slave.pcm mix2, the aplay works well. but if I select the slave.pcm mix1, the aplay gets the info: ALSA lib pcm_direct.c:1462:(_snd_pcm_direct_get_slave_ipc_offset) Invalid type 'dmix' for slave PCM I compare the definition of mix1 with the definition of mix2, I feel they have the identical meaning. so why does the mix2 get the error? thank you!

2 1

[alsa-devel] problems howto send simple 'noteon' event with pyalsa...
by ki.ber.kom.uni.st 14 Mar '08

14 Mar '08

e, i was happy user of PySeq [1] and it was easy to send directly 'noteon' event.. more or less in python interactoin session: import pyseq seq = pyseq.PySeq() seq.createOutPort() event = snd_seq_event() event.setSource(0) event.setSubscribers() event.setNoteOn(ch, note, velocity) event.sendAsIs(seq) it seems that pyalsa will go along alsa development so i tried pyalsa.. but.... i tried this: from pyalsa import alsaseq seq = alsaseq.Sequencer() seq.create_simple_port("myPort", alsaseq.SEQ_PORT_TYPE_APPLICATION, alsaseq.SEQ_PORT_CAP_SUBS_READ | alsaseq.SEQ_PORT_CAP_READ | alsaseq.SEQ_PORT_CAP_WRITE | alsaseq.SEQ_PORT_CAP_SUBS_WRITE) event = alsaseq.SeqEvent(alsaseq.SEQ_EVENT_NOTE) event.set_data({'note.note' : 0x40, 'note.velocity' : 127, 'note.duration' : 1, 'note.off_velocity' : 0}) event.dest = (20, 0) seq.output_event(event) seq.drain_output() after drain it says: "SequencerError: Failed to drain output: Invalid argument" i can connect and disconnect ports around and (20,0) is functional port where i send events with no problems from PySeq... any ideas? do i have to use queues to be able to send 'noteon'.. for my purposes it seems to me that that's overkill.... thanx.. [1] http://www.sci.ccny.cuny.edu/~brinkman/software/pyseq/

3 3

[alsa-devel] [PATCH] Fix ALC662 DAC mixer mutes
by Herton Ronaldo Krzesinski 13 Mar '08

13 Mar '08

Currently ALC662 doesn't suport amp mute for AmpOut in nids 0x02, 0x03, 0x04 (see block diagram in ALC662 datasheet page 3, does M correspond to mute?). The result is that currently mute for "Front Playback Switch", "Surround Playback Switch", "Center Playback Switch" and "LFE Playback Switch" mixer items doesn't work (tested on Asus P5GC-MX motherboard with 3stack-6ch model). The solution I found for this is to mute the proper inputs in 0x0c, 0x0d, 0x0e audio mixers. Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com> diff -p -up linux-2.6.24/sound/pci/hda/patch_realtek.c.orig linux-2.6.24/sound/pci/hda/patch_realtek.c --- linux-2.6.24/sound/pci/hda/patch_realtek.c.orig 2008-03-11 13:45:07.000000000 -0300 +++ linux-2.6.24/sound/pci/hda/patch_realtek.c 2008-03-11 14:01:57.000000000 -0300 @@ -13004,13 +13004,13 @@ static struct hda_channel_mode alc662_5s static struct snd_kcontrol_new alc662_base_mixer[] = { /* output mixer control */ HDA_CODEC_VOLUME("Front Playback Volume", 0x2, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE("Front Playback Switch", 0x02, 0x0, HDA_OUTPUT), + HDA_CODEC_MUTE("Front Playback Switch", 0x0c, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Surround Playback Volume", 0x3, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE("Surround Playback Switch", 0x03, 0x0, HDA_OUTPUT), + HDA_CODEC_MUTE("Surround Playback Switch", 0x0d, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_MONO("Center Playback Volume", 0x04, 1, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_MONO("LFE Playback Volume", 0x04, 2, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE_MONO("Center Playback Switch", 0x04, 1, 2, HDA_INPUT), - HDA_BIND_MUTE_MONO("LFE Playback Switch", 0x04, 2, 2, HDA_INPUT), + HDA_CODEC_MUTE_MONO("Center Playback Switch", 0x0e, 1, 0x0, HDA_INPUT), + HDA_CODEC_MUTE_MONO("LFE Playback Switch", 0x0e, 2, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Headphone Playback Switch", 0x1b, 0x0, HDA_OUTPUT), /*Input mixer control */ @@ -13027,7 +13027,7 @@ static struct snd_kcontrol_new alc662_ba static struct snd_kcontrol_new alc662_3ST_2ch_mixer[] = { HDA_CODEC_VOLUME("Front Playback Volume", 0x02, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Front Playback Switch", 0x02, 2, HDA_INPUT), + HDA_CODEC_MUTE("Front Playback Switch", 0x0c, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Headphone Playback Switch", 0x1b, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME("CD Playback Volume", 0x0b, 0x04, HDA_INPUT), HDA_CODEC_MUTE("CD Playback Switch", 0x0b, 0x04, HDA_INPUT), @@ -13044,13 +13044,13 @@ static struct snd_kcontrol_new alc662_3S static struct snd_kcontrol_new alc662_3ST_6ch_mixer[] = { HDA_CODEC_VOLUME("Front Playback Volume", 0x02, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Front Playback Switch", 0x02, 2, HDA_INPUT), + HDA_CODEC_MUTE("Front Playback Switch", 0x0c, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Surround Playback Volume", 0x03, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Surround Playback Switch", 0x03, 2, HDA_INPUT), + HDA_CODEC_MUTE("Surround Playback Switch", 0x0d, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_MONO("Center Playback Volume", 0x04, 1, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_MONO("LFE Playback Volume", 0x04, 2, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE_MONO("Center Playback Switch", 0x04, 1, 2, HDA_INPUT), - HDA_BIND_MUTE_MONO("LFE Playback Switch", 0x04, 2, 2, HDA_INPUT), + HDA_CODEC_MUTE_MONO("Center Playback Switch", 0x0e, 1, 0x0, HDA_INPUT), + HDA_CODEC_MUTE_MONO("LFE Playback Switch", 0x0e, 2, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Headphone Playback Switch", 0x1b, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME("CD Playback Volume", 0x0b, 0x04, HDA_INPUT), HDA_CODEC_MUTE("CD Playback Switch", 0x0b, 0x04, HDA_INPUT), -- []'s Herton

1 1

[alsa-devel] Hardware and software period size
by Mathieu Monney 13 Mar '08

13 Mar '08

Hi all, I'm currently developping a layer between ALSA and a VoIP library for an embedded device. The device cannot have a different period size than 1024 for playback and 8 for capture (I don't know why :-( ). So my problem is that the VoIP library ask me to have a period size different of the hardware period size. So I decided to read/write to the sound device using the provided software period size rather than the hardware period size.. Is it a good idea? It seems to work but I have some sound quality issues :-( ! Thank you Mathieu

1 0